Concurrent programming (was: Would you start a new Smalltalk project today?)
Locked
Concurrent programming (was: Would you start a new Smalltalk project today?)
 
|
On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <[hidden email]> wrote:
Semaphores _are_ fantastic!! Lock-free algorithms are even cooler. 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Concurrent programming (was: Would you start a new Smalltalk project today?)
|
|
2009/3/23 Michael van der Gulik <[hidden email]>:
> > > On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <[hidden email]> > 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. > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Concurrent programming (was: Would you start a new Smalltalk project today?)
|
|
Rich Hickey the creater of Clojure (functional Lisp) has done a bunch
of nice videos on the language here is one he did on concurrency that is really very good: http://blip.tv/file/812787 At the end, he introduces an ant colony simulation that has similar concurrency problems to your rock falling simulation. It is all done with immutable persistent data structures and transaction memory. I think it is the most exciting new programing language development of the past few years. I wound up watching many of his videos. Smalltalk could do this stuff well. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Concurrent programming (was: Would you start a new Smalltalk project today?)
|
|
In reply to this post by Michael van der Gulik-2
Michael
there is no problem. discussion is also good. Dogma or trolling would be boring :) On Mar 23, 2009, at 12:42 AM, Michael van der Gulik wrote: > > > On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <[hidden email] > > 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 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Concurrent programming (was: Would you start a new Smalltalk project today?)
|
|
In reply to this post by David Finlayson
do you know pointers that explain the interplay between transactional
memory and concurrency/immutable structure. On Mar 23, 2009, at 7:54 AM, David Finlayson wrote: > Rich Hickey the creater of Clojure (functional Lisp) has done a bunch > of nice videos on the language here is one he did on concurrency that > is really very good: > > http://blip.tv/file/812787 > > At the end, he introduces an ant colony simulation that has similar > concurrency problems to your rock falling simulation. It is all done > with immutable persistent data structures and transaction memory. I > think it is the most exciting new programing language development of > the past few years. I wound up watching many of his videos. > > Smalltalk could do this stuff well. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Concurrent programming (was: Would you start a new Smalltalk project today?)
|
|
On 23/03/2009, at 7:05 PM, Stéphane Ducasse wrote: > do you know pointers that explain the interplay between transactional > memory and concurrency/immutable structure. There are many papers on STM that describe the benefits wrt concurrency. Wikipedia has a good explanation http://en.wikipedia.org/wiki/Software_transactional_memory with many subsequent links. The relative weight of the pros and cons vary depending both on the STM implementation (e.g. Clojure uses MVCC) and the language into which STM is embedded. Immutability makes a big difference by reducing contention granularity. Clojure has the additional benefit of explicitly identifying the points are which conflict can occur e.g. Refs. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is no measure of health to be well adjusted to a profoundly sick society. -- Jiddu Krishnamurti _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Concurrent programming (was: Would you start a new Smalltalk project today?)
|
|
In reply to this post by Stéphane Ducasse
Thanks Michael and Antony about this discussion.
cheers, Alexandre On 23 Mar 2009, at 09:30, Stéphane Ducasse wrote: > Michael > there is no problem. > discussion is also good. Dogma or trolling would be boring :) > > On Mar 23, 2009, at 12:42 AM, Michael van der Gulik wrote: > >> >> >> On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <[hidden email] >>> 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 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |