Memory Barriers with STM and MVar

Carter Schonwald carter.schonwald at
Fri May 31 16:52:25 UTC 2019

what the precise guarantees are actually may depend on the platform.

if you look for the barriers, they're in the RTS c codebase
should get you started, theres also read_barrier and write_barrier in the

On Tue, May 28, 2019 at 3:16 PM Andrew Martin <andrew.thaddeus at>

> Perhaps it may be better to open an issue for this information to be added
> to the GHC user manual. Neither the word "barrier" nor the word "fence"
> show up in the context of reordering in the user manual. Having some kind
> of guarantee is extremely important for writing certain types of
> applications. I suspect that both atomically and all the MVar operations
> imply a full memory barrier, but I haven't been able this documented
> anywhere.
> On Fri, May 24, 2019 at 1:38 PM Andrew Martin <andrew.thaddeus at>
> wrote:
>> I've been poking around in old threads and in the GHC source, and I
>> cannot find this documented anywhere. What are the guarantees that GHC
>> provides around load/store reordering when it comes to using MVar or
>> TVar+retry+atomically. For example:
>> import Data.Primitive
>> import Control.Concurrent.MVar
>> ...
>> foo :: IO ()
>> foo = do
>>   ...
>>   writeByteArray myArr 13 (42 :: Word)
>>   putMVar myMVar ()
>> If there is another thread that calls takeMVar followed by `readByteArray
>> myArr 13`, is it guaranteed by GHC to see the 42 that's been written to the
>> array. Same question applies for situations using STM facilities to
>> accomplish blocking behavior that MVar gives us. Any documentation or
>> pointers to places in GHC source where these barriers are guaranteed would
>> be appreciated.
>> --
>> -Andrew Thaddeus Martin
> --
> -Andrew Thaddeus Martin
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list