On Wed, Oct 26, 2011 at 4:24 PM, Bas van Dijk <v.dijk.bas@gmail.com> wrote:
I have one question regarding your use of atomicModifyIORef:
x <- atomicModifyIORef ref (\_ -> (tmstr, ())) x `seq` return ()
Can't you write that as just: writeIORef ref tmstr? If you're not using the previous value of the IORef there's no chance of inconsistency.
From the documentation at http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data-IORef.... :
IORef operations may appear out-of-order to another thread, ... ... atomicModifyIORef acts as a barrier to reordering. Multiple atomicModifyIORef operations occur in strict program order. Based on this description, it seems that atomicModifyIORef is safer for writing to an IORef than writeIORef when there are multiple threads reading and writing it. If my assessment is correct, I think Data.IORef should have an atomicWriteIORef :: IORef a -> a -> IO () function to clarify this. I'm not completely sure about this myself. Could someone confirm this? Moreover, it'd be nice if there were writeIORef' and atomicModifyIORef' functions that force the value. Doing so would help people avoid making the mistake described by the author. It's a really common mistake. - Joey