Objections to runAtomically

[Alastair Reid]

> I don't like runAtomically either, because once again it assumes a
> global lock.  

It has to be a global lock if we are to implement it on NHC and Hugs.
Since we can't block finalizers once they start running, the only way
to get atomicity is to stop them running.  This requires use of a
global lock unless we had (in advance, before the finalizer starts
running) a list of the set of objects that the finalizer is going to
access.  It'd be hard to do this while treating libraries as black
boxes.

> This is fine for GHC or Hugs or NHC on single processors, but it
> would be a pain if you had multiple processors.

By 'pain' you mean slow?

Since > 90% of uses of runAtomically will be with modifyIORef, we can
avoid this overhead by providing atomicModifyIORef in the IORef
library as well.  Multiprocessor GHC is free to implement it more
efficiently if necessary/ convenient.

--
Alastair