On Sep 3, 9:07 pm, Nigel Rantor <wig...@wiggly.org> wrote: > > Right, this is where I would love to have had more experience with Haksell. > > Yes, as soon as you get to a situation where no thread can access shared > state that is mutable your problems go away, you're also getting no work > done becasue the threads, whilst they may be performing lots of > interesting calculations have no way of allowing the rest of the > program, or operating system, know about it. >
Threads could communicate only with channels, message queue, or equivalent. Is what I do that as much as I can, to avoid the headache of sharing data between threads. It is less efficient than the shared data model and adds latency, but ensure that each thread is self-contained, making for safer programming and opening the way to better parallelization. AFAIK erlang Processes and scala Actors implement a similar model at language level. In python, there is kamaelia that implements a similar paradigm, although it is more concerned with logical parallelization than with multitheading performance issue. I believe this kind of paradigms will bring us to the massive multicore world easier than FP. Consider that most FP languages have accepted a compromise and become 'unpure' (i.e. have constructs to change variable in place). Even haskell, the only pure FP language I know (sort of), has things like mutable arrays. All these features expose current FP languages at the same 'shared resource' risks of imperative one, although admittedly at a less level. And FP languages have their own crop of problems - e.g how to deal efficiently with deep recursion levels, parameters passed by copy, huge list built in memory (if you use eager evaluation) or build-up of thunks (if you use lazy evaluation). But then, I'm just a programmer, so I could be easily wrong :-) Ciao ----- FB -- http://mail.python.org/mailman/listinfo/python-list
