Memory Barriers with STM and MVar

Andrew Martin andrew.thaddeus at gmail.com
Fri May 31 17:46:44 UTC 2019


I feel like what I really need is a primop for sticking a
store_load_barrier at an arbitrary place in the code. That would give me
the guarantee I'm looking for. Then I could write:

foo :: IO ()
foo = do
  ...
  writeByteArray myArr 13 (42 :: Word)
  storeLoadBarrier
  putMVar myMVar ()

On Fri, May 31, 2019 at 1:44 PM Andrew Martin <andrew.thaddeus at gmail.com>
wrote:

> Thanks. The does have the information I was looking for. While
> write_barrier gets used in a number of places, store_load_barrier never
> actually gets used anywhere. This makes me suspect that MVar and STM cannot
> be used to coordinate access to memory in this way my example tries to.
> That is unfortunate.
>
> On Fri, May 31, 2019 at 12:52 PM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> 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
>>>
>>
>
> --
> -Andrew Thaddeus Martin
>


-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190531/06547374/attachment.html>


More information about the Libraries mailing list