memory ordering

[Carter Schonwald]

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.schonwald at gmail.com <javascript:_e({}, 'cvml',
> 'carter.schonwald at 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 <
>> choener at tbi.univie.ac.at <javascript:_e({}, 'cvml',
>> '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.
>>>
>>> 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 <javascript:_e({}, 'cvml',
>>> '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 <javascript:_e({}, 'cvml',
>>> '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 <javascript:_e({}, 'cvml',
>>> 'Glasgow-haskell-users at haskell.org');>
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20131222/34ccd7c8/attachment-0001.html>