Counter in atomic-primops not atomic about haskell-lockfree HOT 4 CLOSED

Thanks -- I'll take a look.

from haskell-lockfree.

I think this is resolved now that Ryan's sorted out the broken CPP, right? @rrnewton

from haskell-lockfree.

Yes, this was a horrible horrible bug (issue #15). It was falling through to the vanilla C, NONATOMIC implementations. Terrible! Worst possible thing for an atomic-primops library to do.

Fortunately, it's fixed now as of release 0.5.0.2, if you want to take another look @jberryman ...

Btw, there are similar test cases to this one in the repo, but it's interesting how this one uses "start" MVars. Presumably that's to allow the threads to migrate to other CPUs before blocking, and to thereby increase the degree they are contending? If this does bring the start-times of the threads closer together, we should change all our tests to use it.

from haskell-lockfree.

Well don't beat yourself up! Glad I could help, and looking forward to seeing where all this work leads.

Presumably that's to ... increase the degree they are contending?

Yeah, that was the idea although I didn't think too much about it to be honest. A more paranoid solution would be to have each forked thread block until all it's sibling worker threads have been forked, like:

do readyCount <- newTVar 0
     replicateM_ 2 $ forkIO $ incrementThenRetryUntilEqualsTwo readyCount >> doTest
     ...
     blockMainThreadUntilDone

It also might be advisable to force the cabal tests to fail with a message if run without -N2 or more (if that doesn't already happen).

from haskell-lockfree.