FROM: Ole Agesen ON: Apr 25 '95 at 1:50 pm
Date: Tue, 25 Apr 1995 13:50:31 -0700 To: firstname.lastname@example.org Subject: Re: Support for native OS threads ? Cc: email@example.com Status: RO
From: Reto Kramer firstname.lastname@example.org 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)
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).
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 !
Thanks for the explanation of your scenario. A few of points may be worth mentioning: - The doesNotUnderstand trick exacts a high price in performance. However, in Smalltalk it's hard to avoid it. In Self, it may be possible to build your active objects without relying on doesNotUnderstand quite so much (using dynamic inheritance or delegation, for example). I haven't tried this myself, so cannot be certain, but I think it's possible. - As Dave points out, the whole Self scheduler is written in Self (down to a single primitive), so in principle you can add your own policies and mechanisms. - The Self I/O system is built on non-blocking calls, so doing I/O within one Self process does not block the others.
I don't really understand your point about lower latency in OS threads. If you have to page something in, you have to page it in. I can't see how OS threads will help here.
Adding anything to the Self language (except perhaps new primitives) to support active objects would probably be a very large piece of work. I would experiment entirely within the language at first, to see if you can get what you need.
I'd be willing to provide some assistance if necessary (particularly in explaining parts of the system [like the scheduler]).