Memory fence around stg_atomicModifyMutVarzh
mike at barrucadu.co.uk
Wed Oct 21 12:01:05 UTC 2015
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.
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
Michael Walker (http://www.barrucadu.co.uk)
More information about the ghc-devs