On Thu, Apr 15, 2010 at 7:40 AM, Iain Bason <iain at thebasons.com> wrote:

>
> 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?
>

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.
 In this context ease of synchronisation can still be important, in fact
possibly more important (see the server use case earlier in this thread).

In any case, if preemption does not imply a yield I don't see that this in
itself prevents the use of multiple cores.  I'm working on a multi-threaded
Cog which only switches native threads during FFI calls.  This VM can use
multiple threads for as long as an FFI call is in progress, during which
another native thread will run Smalltalk.  There are many ways to skin the
multi-core cat.

best
Eliot


> Iain
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100415/62957c06/attachment.htm