[Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators

[Bernie Pope]

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
Lennart Augustsson:


http://augustss.blogspot.com/2011/04/ugly-memoization-heres-problem-that-i.html

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110517/a675b357/attachment.htm>