carter.schonwald at gmail.com
Fri Dec 20 17:05:19 UTC 2013
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.
> 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
> > following:
> > > x <- MVector.read vec ix
> > > position <- readIORef posRef
> > and the algorithm is only safe if these two reads are not reordered
> > 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
> > Of course this also relies upon the architecture's memory model, but
> > also guarantees that reads happen in order. However doubts remain; I
> > 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
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Glasgow-haskell-users