[Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

Igor Stasenko siguctua at gmail.com
Sun Mar 22 20:39:38 EDT 2009


2009/3/23 Michael van der Gulik <mikevdg at gmail.com>:
>
>
> On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <antony.blakey at gmail.com>
> wrote:
>>
>> On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote:
>>
>>
>>
>> > Smalltalk, the language rather than the implementation, already has
>> > fantastic support for concurrency. Smalltalkers just don't know how
>> > to use it. We don't need to rethink the model, we just need to learn
>> > to use what we have.
>>
>> Mutexes and semaphores are hardly 'fantastic'. The state of the art in
>> support for concurrency is way beyond what Smalltalk provides -
>> locking is both primitive and generally not scalable.
>>
>
> Semaphores _are_ fantastic!! Lock-free algorithms are even cooler.
>
The difference between lock-free and semaphores is HUGE.
Try to write a simulation which models a bunch of rocks rollong from
the top of mountain, sometimes colliding with each other and breaking
apart on smaller pieces.
Now, let say each thread computing a single rock position in space. To
detect a collision , you have to check/predict the trajectory where it
intersects with another rock. A naive implementation would be to scan
all rocks trajectories/positions and find those which colliding with
concrete rock which single thread simulating.
Now, inevitably you have to use a some collection 'Rocks', and scan it
each time when you need to test for collisions.
Since there are dozens of rocks, each requires to perform very same test.
But remember, sometimes rocks are breaking apart, which means you need
to add a new object(s) to Rocks collection, while removing old one.
Because of that you HAVE to protect access to collection with
semaphore. This means, that for 1000 access requests to this
collection (including: scan, add, remove), only single can be
fullfilled at a single point of time.
Semaphores are fantastic in making such simulation run billion years
on supercomputers. :)


> The language lends itself to building up higher abstractions. Take for
> example Collection and all its subclasses; they're screaming out to have
> parallelised versions made:
>
> c := ConcurrentOrderedCollection new.
> c do: [ :each | ...this part gets executed in parallel...].
>
> The caveat here is that you need to be careful about side-effects.
>
> This is just one example. I have some more rudimentary ideas at:
> http://gulik.pbwiki.com/Parallel+processing.
>
> Oh, and sorry to the Pharo guys for keeping this going. Let us know if you
> don't want threads like this on your list.
>
> Gulik.
>
>
> --
> http://gulik.pbwiki.com/
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-dev mailing list