Memory Barriers with STM and MVar

[Andrew Martin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190528/410b4a5c/attachment.html>