Memory fence around stg_atomicModifyMutVarzh
marlowsd at gmail.com
Wed Oct 21 13:00:32 UTC 2015
On 21/10/2015 13:17, Ben Gamari wrote:
> Michael Walker <mike at barrucadu.co.uk> writes:
>> 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:
>> 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
> 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
More information about the ghc-devs