FROM: Ole Agesen ON: Apr 25 '95 at 1:50 pm

Date: Tue, 25 Apr 1995 13:50:31 -0700 To: kramer@al.esec.ch Subject: Re: Support for native OS threads ? Cc: self-interest@otis.stanford.edu Status: RO

...

From: Reto Kramer kramer@al.esec.ch Subject: Support for native OS threads ? Date: Tue, 25 Apr 95 13:19:37 METDST

Does the current self system support native OS threads ?

(At the moment I am working with ParcPlace Smalltalk and I have about 250 Processes around. It would be nice, if they were on the level of the OS as opposed to the VM and bytecodes, as they are at the moment)

Reto

The Self threads are OS independent like Smalltalk's (implemented with timer interrupts in the Self VM and Self code). Would you mind telling me why you prefer OS level threads, btw? (Not that I disagree with you, I'd just like to hear your reasons - it sounds like you have more massive experience with processes than most people).

Thanks Ole

Let me give you a brief description of our background to explain our need for a lot of threads (here I understand the Smalltalk Process objects as threads too). I do this beeing aware of the fact that the subject might be considered to be more appropriate for another newsgroup (design/general OO). However I am looking for language support for out design approach and self is a candidate !

We are developing a CIM system closely related to the SEMATECH framework model. Our soft-realtime system is beeing implemented in VisualWorks.

Our design describes the system as asynchronous which contributes to the fact that we have a lot of objects that execute methods under "their own processor time". E.g. each piece of production machinery is an active object, whereas the material flowing through the CIM system is mostly passive.

The notion of active and passive objects allows us to use message passing sematics like: synchronous (default for passive objects), asynchronous (default for active objects), future and balking. By default the receiver determines the execution mode of a message sent to it. However the sender may override this default. E.g. An active object can be queried for a result in a synchronous way, overriding the asynchronous default behaviour of the receiver. Our approach uses the doesNotUnderstand trick and uses ideas from the Actalk Smalltalk extension. As in Actalk, active objects wrapped with a "doesNotUnderstand:-shell" so we can get our hands on the messages. By default messages get stored in a queue. The thread that is associated with the active object reads from the queue and evaluates the message under its processor time. Thus the message sent is not evaluated in the sender's thread. N.B. Exception handling in this environment is a very interesting subject.

The advantages I expect from "native-OS-threads" would be:

- lower wake-up latency (today the entire image must be swapped in, if a thread wakes up) - non blocking OS calls (today the entire VM block when doing a C call and thus no threads do not get scheduled or executed during that time)

The need for a lot of threads (and native OS thread support) is only an artifact of the idea to model and implement our system using the high level abstraction of active and passive objects !

The notion of active vs. passive objects has proved to be an advantage in our project because the application developers are shielded from low level process/semaphore/queue related synchronization issues and can work on the a higher abstraction level provided by asynchronous/synchronous/future and balking message passing sematics.

- Is there any attempt to bring the notion of active/passive objects, and multiple message passing sematics into self ? - Is it considered to be a good idea to build these features into the language or should they always be provided by an add on system (if so, things like the CLOS "around/before/after" functions are useful and make the doesNotUnderstand trick obsolete in certain cases).

Looking forward to hearing from you !

Reto