Sequence points... yes, all seems reasonable to me. On 31 March 2006 00:50, John Meacham wrote:
We should drop atomicModifyIORef since we have MVars, for architectures with only a test and set instruction and no atomic exchange, supporting atomicModifyIORef would entail the same overhead as MVars.
Slightly less overhead than an MVar, because you only need one lock/release to implement atomicModifyIORef, but two lock/release combinations are involved in an update of an MVar. atomicModifyIORef would be a sequence point, BTW. Semantically, think of it as having a hidden MVar attached to the IORef: withMVar m $ \_ -> do x <- readIORef r let (x',y) = f x writeIORef r x' return y as long as you have some way to enforce exclusion with respect to other atomicModifyIORef operations on a given IORef, you can implement it like this.
atomicModifyIORef also cannot (easily) be implemented on implementations that use update-in-place rather than indirections for thunk updates.
I don't follow you - how would that make it harder? Cheers, Simon