Objections to runAtomically

[Alastair Reid]

Alastair:
>>  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. 

If you don't believe that runAtomically is necessary, you can't
believe that we will ever call it.  That being so, the performance
overhead shouldn't concern you.  (Implementation effort would be a
different kettle of fish.)

> For one thing runAtomically once again assumes the existence of some
> linear ordering on all state operations performed by the program.

It assumes that side effects can be linearized.  Every theory of
concurrency I know of makes the same assumption.

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

The only repercussion in a multiprocessor system is that calls to
runAtomically must take a global lock.

Global locks have been implemented enough times that the issues have
been figured out many times.

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

The need is for the small number of cases where the state is spread
over a number of mutable variables (IORefs, maybe some mutable arrays,
maybe some C state) and we want to update it atomically.

Even if George's unsafePerformIO trick is correct (I remain doubtful),
its unlikely that Joe Haskell User will apply the trick correctly so
it's better to provide them with a simple alternative.

--
Alastair