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. Cheers, - Ben
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
