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

[dm-list-haskell-cafe at scs.stanford.edu]

At Tue, 17 May 2011 02:18:55 +1000,
Bernie Pope wrote:
> 
>  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.

While I don't know how IORefs work and I'd love to understand this
better, I can't imagine any IORef implementation in which memoIO (in
the blog post) would give the wrong answer on x86.  It might, of
course, cause f x to be evaluated multiple times on the same x.

However, on other CPUs (e.g., the DEC alpha), there could maybe, maybe
be issues.  Though I'm not sure, since to avoid crashes, the alpha
implementation of IORef would need to include a memory barrier.  The
question is whether there is an architecture in which IORef avoids
crashes AND memoIO can give you the wrong answer.  Also, if Simon's
original post means that IORef operations all contain barrier
instructions, it could be that memoIO is simply correct and the blog
post is simply wrong about needing MVars.

David