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? Thanks. -- Michael Walker (http://www.barrucadu.co.uk)