Memory fence around stg_atomicModifyMutVarzh

[Ben Gamari]

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.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151021/1ba57b13/attachment.sig>