On 21/10/2015 13:17, Ben Gamari wrote:
Michael Walker <[email protected]> writes:
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.
Here is the barrier:
(h) = ccall cas(mv + SIZEOF_StgHeader + OFFSET_StgMutVar_var, x, y);
cas() is an external C function defined in includes/stg/SMP.h using
inline assembly.
Cheers
Simon
_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
