[LLVMdev] Reviving the new LLVM concurrency model

[Jianzhou Zhao]

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"...

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"?

On Mon, Jul 18, 2011 at 8:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> There was some discussion a while back about adding a C++0x-style
> memory model and atomics for LLVM a while back
> (http://thread.gmane.org/gmane.comp.compilers.llvm.devel/31295), but
> it got stalled.  I'm going to try and restart progress on it.
>
> Attached are two patches; the first adds a section to LangRef with
> just the memory model, without directly changing the documentation or
> implementation of atomic intrinsics.  This mostly comes from
> https://docs.google.com/View?docID=ddb4mhxz_22dz5g98dd&revision=_latest,
> but it's been modified a bit, so please look at the attached version.
> The second fixes the one place I know of where LLVM violates that
> proposed memory model.
>
> I would appreciate any reviews (primarily for the LangRef bits; I'm
> reasonably confident the patch to LICM is correct).
>
> There was some discussion about allowing targets to implement
> unaligned stores by widening, but I've left that out.  No current
> backend uses such an implementation, so there isn't a substantial
> benefit, and allowing it would break some current optimizations (like
> transforming a memset to an unaligned store).  See also the FIXME in
> the LangRef patch about architectures without a proper single-byte
> store instruction.
>
> -Eli
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



-- 
Jianzhou