[LLVMdev] Reviving the new LLVM concurrency model

[Eli Friedman]

On Mon, Aug 22, 2011 at 1:24 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
> On Mon, Aug 22, 2011 at 3:02 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Mon, Aug 22, 2011 at 11:17 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>>> On Mon, Aug 22, 2011 at 1:02 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>>> On Mon, Aug 22, 2011 at 9:55 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>>>>> In the definition of 'monotonic' ordering,
>>>>> ... "If an address is written monotonically by one thread, and other
>>>>> threads monotonically read that address repeatedly, the other threads
>>>>> must eventually see the write"...
>>>>
>>>> It's supposed to mean that if you have a something like looks like a
>>>> spinloop with monotonic reads, it shouldn't spin forever if the value
>>>> changes.  I'll take another look at rewording that.
>>>>
>>>>> Does this mean if a thread does multi-writes monotonically, monotonic
>>>>> reads from other threads should see all of them? But intuitively, it
>>>>> seems to be fine for a read to ``miss'' some of the writes as long as
>>>>> the writes seen are monotonic in the sense that later reads should see
>>>>> the same write of earlier reads, or any write monotonically after the
>>>>> writes seen.
>>>>>
>>>>> In the case there is only one monotonic write, what does 'eventually'
>>>>> mean? Can we know a write must be seen when some condition holds, for
>>>>> example, a number of instructions executed, the thread that did the
>>>>> write executes a fence, ...?
>>>>>
>>>>> C++ memory model does not have ``unordered'', and "monotonic", but
>>>>> have "modification ordering" (is it same to the relaxed atomic
>>>>> variables the LLVM IR mentions?). If I am compiling C++ to LLVM, can
>>>>> all modification atomic be compiled to monotonic? And when should we
>>>>> use "unordered"?
>>>>
>>>> http://llvm.org/docs/Atomics.html is an attempt to make things much
>>>> more straightforward than the stuff in LangRef.
>>>
>>> This is cool.
>>>
>>> At the end of the "optimization outside atomic" section there are
>>> discussions about "returning undef". Is it the following correct?
>>> * a store/store data race in LLVM leads to undefined behaviors,
>>
>> What exactly is a store-store "race"?  That sounds wrong.
>
> If a program has two stores that are not ordered by happens-before
> relations, does the program have undefined behaviors?

In the LLVM memory model, you cannot get undefined behavior by any
combination of non-atomic loads and stores to valid memory locations;
the undefined behavior only comes into play when you try to use an
'undef'. (although a load which subsequently examines the result would
be 'undef').

> At the end of the "optimization outside atomic" section
>
> ...
> However, LLVM is not allowed to transform the former to the latter: it
> could introduce undefined behavior if another thread can access x at
> the same time.
> ...
>
> Is the ``undefined behavior'' introduced by the addition write "x =
> xtemp"? For example, if a[i] is always false in the original program,
> there is no the write.

Yes (indirectly).

> But I don't think "int xtemp = x;" can introduce undefined behavior,
> if LLVM does not take load/store race as undefined. Am I correct?

Yes, the speculative load is allowed.

-Eli