Well if you hit any weird / surprising / none obvious issues with the memory ordering model, please share! It's also very relevant to some of the ghc hacking I hope to make time for January onwards. <span></span><br><br>
On Sunday, December 22, 2013, John Lato wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Carter,<br><br></div><div>Atomics are more or less what I'm after.<br>
</div><br></div>I've
taken a look at Ryan's work
(<a href="https://github.com/rrnewton/haskell-lockfree/" target="_blank">https://github.com/rrnewton/haskell-lockfree/</a>), and there are certainly
some very useful items there, but I don't see anything quite like what
I'm looking for (except perhaps for a read barrier).<br><br></div>The problem
is that I don't actually need atomic operations for this. I'm just doing reads after all. My concern is that many optimization
pipelines (i.e. LLVM) don't guarantee ordering of reads unless you use
atomic variables.<br><div><br></div><div>The IORef docs warn that IORef
operations may appear out-of-order depending on the architecture's
memory model. On (newer) x86, loads won't move relative to other loads,
so that should be ok, and Haskell's semantics should guarantee that two IO operations will happen in program order.<br><br>It's the Haskell semantics guarantee I'm concerned about; I guess I'm not entirely sure I believe that it's implemented properly (although I have no reason to believe it's wrong either). Perhaps I'm just overly paranoid.<br>
<br></div><div>John Lato<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 20, 2013 at 9:05 AM, Carter Schonwald <span dir="ltr"><<a href="javascript:_e({}, 'cvml', 'carter.schonwald@gmail.com');" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br>
<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">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><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="javascript:_e({}, 'cvml', 'choener@tbi.univie.ac.at');" target="_blank">choener@tbi.univie.ac.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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="javascript:_e({}, 'cvml', 'jwlato@gmail.com');" target="_blank">jwlato@gmail.com</a>> <a href="tel:%5B20.12.2013%2002" value="+12012201302" target="_blank">[20.12.2013 02</a>:36]:<br>
<div><div>> 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="javascript:_e({}, 'cvml', 'Glasgow-haskell-users@haskell.org');" target="_blank">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="javascript:_e({}, 'cvml', 'Glasgow-haskell-users@haskell.org');" target="_blank">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>
</div></div></blockquote></div><br></div></div>
</blockquote>