memory ordering

[Christian Höner zu Siederdissen]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20131220/ec06a300/attachment.sig>