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?
I'm afraid I don't know off the top of my head but hopefully Simon Marlow will be able to shed some more light here. When he does it would be great if you could write a nice comment explaining this logic and either open a Phabricator Diff or send the text to me so I can merge it. Cheers, - Ben