Objections to runAtomically

[George Russell]

Alastair Reid wrote:
[snip]
> > 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?
Yes.
> 
> 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.
[snip]
I'm not convinced the overhead is going to be all in modifyIORef.
For one thing runAtomically once again assumes the existence of some
linear ordering on all state operations performed by the program.
I don't have any experience of programming for multiple processors so
I don't know what repercussions it would have for the run-time system,
but it seems possible that there would be some, even in stateful operations
which have nothing to do with runAtomically.  It seems to me that the
majority of locking in a multi-processor system is going to be one-to-one;
one processor wants permission to get at a bit of state owned by another
processor.  However you are asking for something different, where one
processor wants to broadcast a stop-running message to every single other
processor, at the same time as perhaps other processors are also trying
to do the same thing (so you need some mechanism for arbitration).  Of
course it will be possible, but since Alastair seems to be happy for the
IORef to contain atomicModifyIORef anyway, I don't see a pressing need for
the additional primitive.