On Wed, 2010-12-01 at 01:28 +0100, Mitar wrote:

Hi!

On Wed, Dec 1, 2010 at 12:37 AM, Duncan Coutts wrote:

...

I've not looked at it in detail, I just wanted to mention that I would be nervous about accepting this unless someone like Simon Marlow reads it over and decides the locking works.

I think he did?

http://hackage.haskell.org/trac/ghc/ticket/4535#comment:2

Oh sorry. When I said I've not looked at it in detail, that included not reading the ticket, just your email :-)

...

This sort of stuff is notoriously subtle, for example Neil Mitchell is convinced we have a deadlock bug in the current Chan code (without using isEmptyChan), but he cannot pin it down (but using his own trivial Chan impl cures the deadlock).

Can you give me a link to a test code which fails with current implementation of Chan? Or does this problems with pinning it down means that there wasn't yet simple code which would show the problem?

You can ask him, since it was some time ago when he mentioned it, but I think narrowing it down was part of the problem. Duncan

...

...

...

I've not looked at it in detail, I just wanted to mention that I would be nervous about accepting this unless someone like Simon Marlow reads it over and decides the locking works.

I think he did?

http://hackage.haskell.org/trac/ghc/ticket/4535#comment:2

Oh sorry. When I said I've not looked at it in detail, that included not reading the ticket, just your email :-)

...

...

This sort of stuff is notoriously subtle, for example Neil Mitchell is convinced we have a deadlock bug in the current Chan code (without using isEmptyChan), but he cannot pin it down (but using his own trivial Chan impl cures the deadlock).

Can you give me a link to a test code which fails with current implementation of Chan? Or does this problems with pinning it down means that there wasn't yet simple code which would show the problem?

You can ask him, since it was some time ago when he mentioned it, but I think narrowing it down was part of the problem.

Was it this?

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

No. I never managed to narrow it down enough to a test case that showed Chan was at fault, but I'm still "slightly wary" of it - eliminating Chan made the bug go away, but that's hardly conclusive. It's possible what I was actually seeing was a runtime bug instead (could be http://hackage.haskell.org/trac/ghc/ticket/4835 - that bug was narrowed down from something with similar characteristics to the program which was having problems). What I did learn is that MVars (while great) are too complex for highly fallible humans, and I want mathematical proofs and extensive randomized testing on all concurrency primitives. Thanks, Neil

Hi Mitar,

...

I never managed to narrow it down enough to a test case that showed Chan was at fault, but I'm still "slightly wary" of it - eliminating Chan made the bug go away, but that's hardly conclusive.

And it is still happening with current trunk version? Does it happen with both -threaded and without it?

No idea if it happens with anything after 6.12.3. I think it happened in threaded and without.

Because maybe it is nothing wrong with a primitive itself, but just its implementation.

Entirely possible - or the use of that primitive makes latent bugs in other functions show up. My knowledge on this bug can be best described as "vaguely uneasy" - I have no good technical information on it. Thanks, Neil

Hi! On Wed, Dec 1, 2010 at 12:55 AM, Antoine Latter wrote:

All of this really feels like what STM is good at. It might help if you explained why TChans are not well suited to your task.

Because it has too much overhead (I haven't tested it for my particular application but it is based on comment for isEmptyChan). I understand that Chans are more lightweight and once isEmptyChan was deprecated I discovered that for my purposes (non-blocking read) I do not need isEmptyChan and that code can be written without problems isEmptyChan has (mostly because there is a subtle change in semantics). So sometimes you have a work to do and you just want to check if there is something new in Chan and if it is not continue with your work. If you are interested where I am using it you can check my library Etage: http://hackage.haskell.org/package/Etage where I have such function: slurpChan :: Chan a -> IO [a] slurpChan chan = slurpChan' [] where slurpChan' cs = do mc <- tryReadChan chan case mc of Nothing -> return cs Just c -> slurpChan' (c:cs) Mitar

Hi! On Fri, Dec 3, 2010 at 4:13 PM, Simon Marlow wrote:

If you have many threads beating on the same Chan, then in that case the STM version may be a lot slower because it doesn't have the single-wakeup property that MVars have.  That's the tradeoff.

Hm, in fact (for my application) I have mostly one reader and one writer for every Chan (or maybe just a few). I am using Chans to communicate between threads. So in most cases two threads communicate over one Chan. Mitar