<div dir="ltr"><div>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:</div><div><br></div><div><div>foo :: IO ()</div><div>foo = do</div><div>  ...</div><div>  writeByteArray myArr 13 (42 :: Word)</div><div>  storeLoadBarrier<br></div><div>  putMVar myMVar ()</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 31, 2019 at 1:44 PM Andrew Martin <<a href="mailto:andrew.thaddeus@gmail.com">andrew.thaddeus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 31, 2019 at 12:52 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">what the precise guarantees are actually may depend on the platform.<div><br></div><div>if you look for the barriers, they're in the RTS c codebase</div><div><a href="https://github.com/ghc/ghc/blob/bf73419518ca550e85188616f860961c7e2a336b/includes/stg/SMP.h#L24" target="_blank">https://github.com/ghc/ghc/blob/bf73419518ca550e85188616f860961c7e2a336b/includes/stg/SMP.h#L24</a><br></div><div>should get you started, theres also read_barrier and write_barrier in the rts</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 28, 2019 at 3:16 PM Andrew Martin <<a href="mailto:andrew.thaddeus@gmail.com" target="_blank">andrew.thaddeus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 24, 2019 at 1:38 PM Andrew Martin <<a href="mailto:andrew.thaddeus@gmail.com" target="_blank">andrew.thaddeus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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:</div><div><br></div><div>import Data.Primitive</div><div>import Control.Concurrent.MVar</div><div>...</div><div>foo :: IO ()</div><div>foo = do</div><div>  ...</div><div>  writeByteArray myArr 13 (42 :: Word)</div><div>  putMVar myMVar ()</div><div><br></div><div>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.<br></div><div><br>-- <br><div dir="ltr" class="gmail-m_8168210848002989016gmail-m_7980579221270230558gmail-m_-7355561558839482223gmail-m_-3561294555708456542gmail_signature">-Andrew Thaddeus Martin</div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_8168210848002989016gmail-m_7980579221270230558gmail-m_-7355561558839482223gmail_signature">-Andrew Thaddeus Martin</div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_8168210848002989016gmail_signature">-Andrew Thaddeus Martin</div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">-Andrew Thaddeus Martin</div>