Re: Pragmatic concurrency Re: multiple computations, same input
On Thu, Mar 30, 2006 at 05:05:30PM +0200, Tomasz Zielonka wrote:
> Actually, it may require no effort from compiler implementors.
> I just managed to get the desired effect in current GHC! :-)
More specifically: in uniprocessor GHC 6.4.1.
> I implemented your idea of stepper by writing the function stepper that
> rewrites the list invoking "yield" every 500 processed elements. This
> way I can concurrently consume the list without the space leak - when a
> thread evaluates too many list elements, it gets preempted. I think it
> suffices if RTS employs a round-robin scheduler. I am not sure it's
I just realised that this technique will only work on uniprocessors! :-(
I relies on only one thread running at any moment. If there are multiple
CPUs, yielding won't stop the current thread from consuming the list.
> The code isn't as beautiful as the naive wc implementation. That's
> because I haven't yet thought how to hide newEmptyMVar, forkIO, putMVar
> i takeMVar. Perhaps someone will come up with a solution to this.
Here is my attempt to make the code more pure. The "concurrently"
combinator uses CPS, because otherwise it was a bit difficult to split
evaluation into two phases - first forking the thread, second taking the
result from an MVar. I also tried using additional data constructor
wrapper for the result, so first phase occured when forcing the
constructor, and the second when forcing it's parameter, but it was
tricky to use it properly considering that "let" and "where" bindings
use irrefutable patterns.