MVar semantics: proposal
simonmar at microsoft.com
Fri Mar 31 07:43:15 EST 2006
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
> 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'
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
> atomicModifyIORef also cannot (easily) be implemented on
> that use update-in-place rather than indirections for thunk updates.
I don't follow you - how would that make it harder?
More information about the Haskell-prime