We've got a few GSOCs proposed (one or two of which will be funded) that are implementing concurrent data structures.  The following one is highly rated and targets concurrent hash tables:

    https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/lorehead/1

Loren isn't decided on which algorithm to implement yet.  The concurrent tries look interesting, but I don't understand their trade-offs yet compared to the other algorithms mentioned in the above proposal.

  -Ryan

P.S. Several of these algorithms require a casArray# primop as well as casMutVar#.  I've got a patch out for this, but it needs more testing and then to be incorporated in HEAD so that the GSOC students can use it. 


On Fri, Apr 20, 2012 at 9:25 AM, Milan Straka <fox@ucw.cz> wrote:
Hi Simon,

> I went to Aleksandar Prokopec's talk about Concurrent Tries at the Scala day earlier this week.  I thought it was pretty cool. Here's the paper.
>
> http://infoscience.epfl.ch/record/166908/files/ctries-techreport.pdf
>
> http://lampwww.epfl.ch/~prokopec/ctries-snapshot.pdf

Nice :)

> Maybe we should have a Haskell version?  Maybe we already do?

I think we do not have any nontrivial concurrent structures
(we have MVar and FIFO + Semaphore built on top of it).

Most of work seem to be done on persistent structures. On that front,
Johan's unordered-containers package implements the hash tries,
which are roughly the described CTries without concurrent updates.

I am not sure it would be worth implementing a structure in Haskell
that is inherently concurrent. For me it was always enough to wrap
a persistent structure in an MVar, so updates are performed sequentially
and accesses can be made in parallel.

Such a structure would probably have to be strict and in an ST monad,
to get a usable and deterministic behaviour.

Any thoughts?

Cheers,
Milan

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries