MVar semantics: proposal

[John Meacham]

On Fri, Mar 31, 2006 at 01:43:15PM +0100, Simon Marlow 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.

hmm.. is atomicModifyIORef meant to be atomic with respect to all other
IORef calls or _just_ other atomicModifyIORef calls? because if the
second then that is a whole lot easier to implement and I could be on
board with that. :)

> 
> > 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?

for instance in a TIM implementation (do any exist?) you have both a
code pointer and a frame address to represent a value, most arches don't
have an atomic way to set two memory locations at once. However, these
implementations perhaps could use a single indirection just for
implementing IORefs... jhc would be in this boat as it modifies values
by rewriting nodes, not by swizzling pointers, but I can make IORefs go
through an indirection if needed.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈