Re: BlockedIndefinitelyOnMVar exception

[Simon Marlow]

On 04/07/2010 21:51, Neil Mitchell wrote:

http://hackage.haskell.org/trac/ghc/ticket/4154


Yup, that's a bug.  Not clear if it's fixable.


http://hackage.haskell.org/trac/ghc/ticket/3527


That too.  A very similar bug in fact, if there is a fix it will probably
fix both of them.  The problem is that readChan holds a lock on the read end
of the Chan, so neither isEmptyChan nor unGetChan can work when a reader is
blocked.


I wrote my Chan around the abstraction:

data Chan a = Chan (MVar (Either [a] [MVar a]))

The Chan either has elements in it (Left), or has readers waiting for
elements (Right). To get the fairness properties on Chan you might
want to make these two lists Queue's, but I think the basic principle
still works. By using this abstraction my Chan was a lot simpler. With
this scheme implementing isEmpyChan or unGetChan would both work
nicely. My Chan was not designed for performance. (In truth I replaced
the Left with IntMap a, and inserted elements with a randomly chosen
key, but the basic idea is the same.)


I like the idea.  But what happens if one of the blocked threads gets 
killed by a killThread (e.g. a timeout) while it is waiting?  Won't we 
still give it an element of the Chan sometime in the future?  Perhaps 
this doesn't happen in your scenario, but it seems to throw a spanner in 
the works for using this as a general-purpose implementation.


The STM version doesn't have this bug, of course :-)  But then, it 
doesn't have fairness either.


Cheers,
Simon


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: BlockedIndefinitelyOnMVar exception

[Neil Mitchell]

 I wrote my Chan around the abstraction:

 data Chan a = Chan (MVar (Either [a] [MVar a]))

 The Chan either has elements in it (Left), or has readers waiting for
 elements (Right). To get the fairness properties on Chan you might
 want to make these two lists Queue's, but I think the basic principle
 still works. By using this abstraction my Chan was a lot simpler. With
 this scheme implementing isEmpyChan or unGetChan would both work
 nicely. My Chan was not designed for performance. (In truth I replaced
 the Left with IntMap a, and inserted elements with a randomly chosen
 key, but the basic idea is the same.)

 I like the idea.  But what happens if one of the blocked threads gets killed
 by a killThread (e.g. a timeout) while it is waiting?  Won't we still give
 it an element of the Chan sometime in the future?  Perhaps this doesn't
 happen in your scenario, but it seems to throw a spanner in the works for
 using this as a general-purpose implementation.

I hadn't thought of that at all - my scenario doesn't have any threads
being killed. With the thought of threads dying concurrency
abstractions become significantly harder - I hadn't quite realised how
hard that must make it.

Thanks, Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users