On 13/05/2011 21:12, Bernie Pope wrote:
Could you please point me to more information about the sequential
consistency of IORefs? I was looking for something about this recently
but couldn't find it. I don't see anything in the Haddock for Data.IORef.
Yes, it's not actually documented as far as I know, and we should fix that.
Thanks Simon. I was thinking about this in the context of a blog post by Lennart Augustsson:
He says that "There's no guarantee about readIORef and writeIORef when doing multi-threading.". But I was wondering if that was true, and if it were, what the consequences would be. If you read his reply to my question on the blog, then I believe that he was saying that sequential consistency was not guaranteed.
If you have time to read his blog article, I wonder if you could comment on the need (or lack of need) for MVars or atomicModifyIORef? If I understand correctly, it would be okay to use readIORef/writeIORef, assuming that it is okay for some computations to be repeated.
But if you think about it, sequential consistency is really the only sensible policy: suppose one processor creates a heap object and writes a reference to it in the IORef, then another processor reads the IORef. The writes that created the heap object must be visible to the second processor, otherwise it will encounter uninitialised memory and crash. So sequential consistency is necessary to ensure concurrent programs can't crash.
Yes, I agree, and that was what I was thinking. Otherwise well-typed programs could go horribly wrong.
For some background there was a discussion about this on the haskell-prime mailing list a few years ago, I think.
Thanks, I try to dig it up.
Cheers,
Bernie.