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 < choe...@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 <jwl...@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@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users