Sun Oct 23 10:51:38 CEST 2011
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.
More information about the Haskell