Objections to runAtomically

[George Russell]

I don't like runAtomically either, because once again it assumes a global lock.  This
is fine for GHC or Hugs or NHC on single processors, but it would be a pain if you had
multiple processors.  You can't avoid locking between processors altogether of course;
atomicModifyPVars and the unsafePerformIO hack I just posted require data to be
updated consistently (you don't want the same unsafePerformIO being evaluated twice).
However that is not so bad because the locking is only on particular bits of data;
it's reasonable that access to particular thunks or PVars will be "owned" by one 
processor or another, so that if two processors are working on independent bits of
state they can chug along perfectly happily without locking each other, and only need
to talk when one processor wants to get at a bit of state owned by another.

Although Alastair suggests compilers might try to spot when runAtomically can be used
safely without stopping all but one processor, I think analysis of IO actions to check for 
potential conflicts might be even harder than getting Hugs to run Haskell finalizers 8-)
It would require region analysis and probably worse.

However we don't really need to discuss this anyway, since I don't think either 
runAtomically or atomicallyModifyIORef need to be in the FFI standard.  I'm quite happy
to leave this open.