Is this a concurrency bug in base?

[Simon Marlow]

On 10/10/2011 09:04, Simon Peyton-Jones wrote:
> Thank you for the detailed investigation. I have not followed all the
> details of this thread, but I *think* that it may (happily) represent a
> bug in generating TypeReps that is already fixed.
>
> ·We used to have a global cache from which we generated unique Int keys
> corresponding to type constructors. The trouble with this was that (a)
> you weren’t guaranteed to get the same key in every run, and (b) the
> cache was not initially designed to be thread-safe, and I’m not sure
> that we’d closed all race conditions.

Indeed, I don't think we closed *any* race conditions.  The code looks 
completely unthreadsafe to me.  There's a non-atomic lookup and update 
in the cache, and a non-atomic genSym to get new keys.  It's pretty bad 
that we didn't notice this or fix it earlier.

Sorry about the bug.  As Simon said, 7.2 and later should fix it.

Cheers,
	Simon


> ·But NOW we generate a MD5 hash, or fingerprint, of the type. So there
> is no global cache, no race condition, and you should get the same
> behaviour ever time.
>
> In short, can you try with 7.2?
>
> Thanks
>
> Simon
>
> *From:*glasgow-haskell-users-bounces at haskell.org
> [mailto:glasgow-haskell-users-bounces at haskell.org] *On Behalf Of
> *Jean-Marie Gaillourdet
> *Sent:* 09 October 2011 12:53
> *To:* glasgow-haskell-users
> *Subject:* Is this a concurrency bug in base?
>
> Hi,
>
> I am working on a library I'd like to release to hackage very soon, but
> I've found a problem with supporting GHC 6.12 and GHC 7.0.
> Consider the following program:
>
> import Control.Concurrent
> import Data.Typeable
>
> main :: IO ()
> main =
> do { fin1 <- newEmptyMVar
> ; fin2 <- newEmptyMVar
>
> ; forkIO $ typeRepKey (typeOf ()) >>= print >> putMVar fin1 ()
> ; forkIO $ typeRepKey (typeOf ()) >>= print >> putMVar fin2 ()
>
> ; () <- takeMVar fin1
> ; () <- takeMVar fin2
> ; putStrLn "---"
> ; return ()
> }
>
> When compiled with GHC 7.0.x or GHC 6.12.x, it should print two
> identical numbers. Sometimes it does not.
> To reproduce this compile and execute as follows:
>
> $ ghc-7.0.3 -rtsopts -threaded TypeRepKey.hs -o TypeRepKey
> $ while true ; do ./TypeRepKey +RTS -N ; done
> 0
> 0
> ---
> 0
> 0
> ---
> 0
> 0
> ---
> 0
> 1
> ---
> 0
> 0
> ---
> …
>
> Ideally you should get an infinite number of zeros but once in a while
> you have a single(!) one in between. The two numbers of one program run
> should be identical, but their values may be arbitrary. But it should
> not be possible to have single outliers.
>
> This only happens when executed with more than one thread. I've also a
> somewhat larger program which seems to indicate that fromDynamic fails
> occasionally. I can post it as well if it helps. This seems to be a
> Heisenbug as it is extremely fragile, when adding a "| grep 1" to the
> while loop it seems to disappears. At least on my computers.
>
> All this was done on several Macs running the latest OS X Lion with ghc
> 7.0.3 from the binary distribution on the GHC download page.
>
> Actually, I am trying to find a method to use a "type" as key in a map
> which works before GHC 7.2. I'd be glad to get any ideas on how to
> achieve that, given that typeRepKey seems to buggy.
>
> I'd be happy to get any comments on this matter.
>
> Regards,
> Jean
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users