Well if you hit any weird / surprising / none obvious issues with the memory ordering model, please share! It's also very relevant to some of the ghc hacking I hope to make time for January onwards.
On Sunday, December 22, 2013, John Lato wrote: > Hi Carter, > > Atomics are more or less what I'm after. > > I've taken a look at Ryan's work ( > https://github.com/rrnewton/haskell-lockfree/), and there are certainly > some very useful items there, but I don't see anything quite like what I'm > looking for (except perhaps for a read barrier). > > The problem is that I don't actually need atomic operations for this. I'm > just doing reads after all. My concern is that many optimization pipelines > (i.e. LLVM) don't guarantee ordering of reads unless you use atomic > variables. > > The IORef docs warn that IORef operations may appear out-of-order > depending on the architecture's memory model. On (newer) x86, loads won't > move relative to other loads, so that should be ok, and Haskell's semantics > should guarantee that two IO operations will happen in program order. > > It's the Haskell semantics guarantee I'm concerned about; I guess I'm not > entirely sure I believe that it's implemented properly (although I have no > reason to believe it's wrong either). Perhaps I'm just overly paranoid. > > John Lato > > On Fri, Dec 20, 2013 at 9:05 AM, Carter Schonwald < > carter.schonw...@gmail.com <javascript:_e({}, 'cvml', > 'carter.schonw...@gmail.com');>> wrote: > >> 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 <javascript:_e({}, 'cvml', >> '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 <javascript:_e({}, 'cvml', >>> '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 <javascript:_e({}, 'cvml', >>> 'Glasgow-haskell-users@haskell.org');> >>> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org <javascript:_e({}, 'cvml', >>> '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
