<div dir="ltr">Hey John, so you're wanting atomic reads and writes? <div><br></div><div>I'm pretty sure that you want to use atomic memory operations for this.  I believe Ryan Newton has some tooling you can use right now for that.</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 20, 2013 at 3:57 AM, Christian Höner zu Siederdissen <span dir="ltr"><<a href="mailto:choener@tbi.univie.ac.at" target="_blank">choener@tbi.univie.ac.at</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi John,<br>
<br>
I guess you probably want to "pseq x". See below for an example. Since your 2nd<br>
action does not depend on your 1st.<br>
<br>
Gruss,<br>
Christian<br>
<br>
<br>
import Debug.Trace<br>
import GHC.Conc<br>
<br>
main = do<br>
  x <- return (traceShow "1" $ 1::Int)<br>
  -- x `pseq` print (2::Int)<br>
  print (2::Int)<br>
  print x<br>
<br>
<br>
* John Lato <<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>> <a href="tel:%5B20.12.2013%2002" value="+12012201302">[20.12.2013 02</a>:36]:<br>
<div><div class="h5">>    Hello,<br>
><br>
>    I'm working on a lock-free algorithm that's meant to be used in a<br>
>    concurrent setting, and I've run into a possible issue.<br>
><br>
>    The crux of the matter is that a particular function needs to perform the<br>
>    following:<br>
><br>
>    > x <- MVector.read vec ix<br>
>    > position <- readIORef posRef<br>
><br>
>    and the algorithm is only safe if these two reads are not reordered (both<br>
>    the vector and IORef are written to by other threads).<br>
><br>
>    My concern is, according to standard Haskell semantics this should be<br>
>    safe, as IO sequencing should guarantee that the reads happen in-order.<br>
>    Of course this also relies upon the architecture's memory model, but x86<br>
>    also guarantees that reads happen in order.  However doubts remain; I do<br>
>    not have confidence that the code generator will handle this properly.  In<br>
>    particular, LLVM may freely re-order loads of NotAtomic and Unordered<br>
>    values.<br>
><br>
>    The one hope I have is that ghc will preserve IO semantics through the<br>
>    entire pipeline.  This seems like it would be necessary for proper<br>
>    handling of exceptions, for example.  So, can anyone tell me if my worries<br>
>    are unfounded, or if there's any way to ensure the behavior I want?  I<br>
>    could change the readIORef to an atomicModifyIORef, which should issue an<br>
>    mfence, but that seems a bit heavy-handed as just a read fence would be<br>
>    sufficient (although even that seems more than necessary).<br>
><br>
>    Thanks,<br>
>    John L.<br>
<br>
</div></div>> _______________________________________________<br>
> Glasgow-haskell-users mailing list<br>
> <a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
<br>
<br>_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
<br></blockquote></div><br></div>