<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>