memory ordering

[Carter Schonwald]

Hey John, so you're wanting atomic reads and writes?

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.


On Fri, Dec 20, 2013 at 3:57 AM, Christian Höner zu Siederdissen <
choener at tbi.univie.ac.at> wrote:

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