Memory fence around stg_atomicModifyMutVarzh

[Simon Marlow]

On 21/10/2015 13:17, Ben Gamari wrote:
> Michael Walker <mike at barrucadu.co.uk> 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