Concurrent collections

[Ryan Newton]

>
> I'd really like to see some applications that are suffering here, and
> analyse whether it really is contention for the shared data structure, and
> if so, whether there's anything else we can do.  Ryan, do you have anything?


Only the monad-par (and new meta-par) schedulers.  There, we've certainly
had problems with contention on IORefs *AND* with extra GC pressure
resulting from functional updates rather than in-place updates (which some
of these mutable concurrent structures alleviate).  However, it would be
nice to know with more clarity what exactly is keeping us from having
scheduler overhead more competitive with sparks, because I can't
confidently say that it is only the above issues.

One contention problem we have is that we keep adding brand new pieces of
functionality (like the CPU/GPU scheduling) and inevitably in the interest
of fast prototyping we initially use something basic for concurrently
accessed data that performs poorly.
   Ultimately, I think the fundamental problem applications that have a
single point of contention (MVar/IORef) between all or most threads.  Even
the best possible implementation of a single IORef or a single MVar, (for
example using CAS for update than atomicModifyIORef), will still be a
bottleneck on larger SMP systems.
   From our perspective, what we really want is the ability to drop in
logically *singular* shared data structures (like the concurrent bag),
which are actually using TLS behind the scenes to access mostly disjoint
memory addresses.  That's the place where we get a big design win in terms
of keeping the client code simple but also getting scalability.  (Those
concurrent bags in particular perform really well and are basically a
complete work-stealing implementation in a box.)

Looking forward -- we've got a real medical imaging app that we've started
working on; I'll let you know if there are any particular examples of data
structure contention there.  But for now the monad-par/meta-par schedulers
are the only example I've got.

Cheers,
  -Ryan


    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 at haskell.org <javascript:;>
>>    http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>>
>>
>>
>>
>> ______________________________**_________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120424/311e9002/attachment.htm>