Are Squeak processes pre-emptive?

> After all, the higher priority job could always just force a cooperating
> job to yield if needed.

But it would be better for the cooperating process to be able to put
*itself* to the back of the line..  That way, the "cooperative" nature
of the process-scheduling behavior is localized in the business-logic
rather than centralized in a process-manager.  Something like;
Processor yield: true or Processor yield: false?

>>>>> "Chris" == Chris Muller <[hidden email]> writes:

>> After all, the higher priority job could always just force a cooperating
>> job to yield if needed.

Chris> But it would be better for the cooperating process to be able to put
Chris> *itself* to the back of the line..  That way, the "cooperative" nature
Chris> of the process-scheduling behavior is localized in the business-logic
Chris> rather than centralized in a process-manager.  Something like;
Chris> Processor yield: true or Processor yield: false?

I believe "yield" already means "back of the line", which it should.  If
yield put itself in the front of the line, it'd just start running
again!

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

On Apr 13, 2010, at 3:53 PM, Eliot Miranda wrote:

> A cooperative scheduler is one in which it is guaranteed that  
> another process does not run until the active process chooses to  
> yield.  This makes it easy to implement particular forms of  
> synchronisation because processes are not preemptive.

But it also makes it impossible to take advantage of multiple cores.  
Is the ease of synchronization really worth it?

Iain

On Apr 15, 2010, at 10:02 AM, Eliot Miranda wrote:
> If there existed a Squeak VM which had true concurrency and could use multiple cores then a high-priority process would not necessarily preempt a lower-priority process in the first place and hence ensuring fairness would require additional implementation work.  Essentially if and when Smalltalk VMs do move to true concurrency and multiple cores the scheduler will have to be rethought and rewritten and it would probably be a good idea to take the line Igor has with much more control at the image level.  Note that fundamentals like Processor activeProcess would no longer work.  One would need e.g. a pseudo-variable thisProcess.
>
> But for the moment no such Squeak VM is in existence.  Those Squeak systems which do use multiple cores, Igor's Hydra, and Sam and Dave's Tilera64, replicate images so there are many green-threaded images networked together.  


I don't think that this is true for the Tilera64 VM.  It's been a while since I looked at the paper, but I'm pretty sure that multiple processors are operating on the same object memory.  Am I mistaken?

Cheers,
Josh