Christian Höner zu Siederdissen
choener at tbi.univie.ac.at
Fri Dec 20 08:57:17 UTC 2013
I guess you probably want to "pseq x". See below for an example. Since your 2nd
action does not depend on your 1st.
main = do
x <- return (traceShow "1" $ 1::Int)
-- x `pseq` print (2::Int)
* John Lato <jwlato at gmail.com> [20.12.2013 02:36]:
> 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
> > 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
> 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).
> John L.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the Glasgow-haskell-users