Memory Barriers with STM and MVar

[Carter Schonwald]

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

if you look for the barriers, they're in the RTS c codebase
https://github.com/ghc/ghc/blob/bf73419518ca550e85188616f860961c7e2a336b/includes/stg/SMP.h#L24
should get you started, theres also read_barrier and write_barrier in the
rts

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

> 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 gmail.com>
> 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 haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190531/a606cc56/attachment.html>