[Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
florbitous at gmail.com
Mon May 16 18:18:55 CEST 2011
On 16 May 2011 19:56, Simon Marlow <marlowsd at gmail.com> wrote:
> 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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe