On 23/03/2009, at 12:32 AM, Stéphane Ducasse wrote:
Green threads make some underlying implementation details easier, but at the language level the difference they make is determined by the interleaving guarantees they provide, and the extent to which the user can take advantage of those guarantees e.g. the yield-point model.
IMO the solution to concurrency is not to simply add native threads - it also requires a more functional type of programming, and that can be largely provided by immutable data structures and more powerful abstractions, such as those provided in Clojure.
can you illustrate that point?
Immutable data makes concurrency easier because you avoid concurrent modification and eliminate synchronisation issues. Clojure adds data types with specific concurrency semantics. Here's some exposition: http://clojure.org/concurrent_programming
Another question I would love to have immutability bit for pharo. Now if you have immutable collection then I imagine that - you should copy them when you want to modify them (functional)
That happens automatically. Modification operations are functional e.g. f(data) -> data' data' is a different object than data, which remains unchanged. Efficiently implementing this is the key, but it's been done.
- I was wondering if the object that you put such immutable data structure should also be immutable
Not necessarily - in the case of Clojure you might put a Ref/Var/Atom/ Agent into an immutable structure, and those objects have their own concurrency semantics as described in the link above. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Borrow money from pessimists - they don't expect it back. -- Steven Wright