Re:Re: Support for native OS threads ?

[Reto Kramer <kramer@al.esec.ch>]

> 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