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)
_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
