Memory fence around stg_atomicModifyMutVarzh

[Michael Walker]

Hello,

I've been trying to figure out where exactly the synchronisation guarantee of
`atomicModifyIORef` comes from, I've gone down a bit of a rabbit-hole of function
calls and macro expansions, and wanted to check I'd got the right idea.

**Assumption:** `stg_atomicModifyMutVarzh` imposes a barrier to reordering, as
described in the Data.IORef documentation.

Call tree:

    stg_atomicModifyMutVarzh
      dirty_MUT_VAR
        recordClosureMutated
          recordMutableCap
            allocBlock_lock
              ACQUIRE_SM_LOCK -> ACQUIRE_LOCK -> pthread_mutex_lock

**Conclusion:** `pthread_mutex_lock` imposes a memory barrier, and it is through
this rather indirect chain of function calls that `stg_atomicModifyMutVarzh`
gets its barrier property.

Is this correct? Or is there a more direct barrier invocation that I have
missed?

Thanks.

-- 
Michael Walker (http://www.barrucadu.co.uk)