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⑈
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
