[LLVMdev] Reviving the new LLVM concurrency model

[Eli Friedman]

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.

-Eli