[LLVMdev] Reviving the new LLVM concurrency model

[Jeffrey Yasskin]

On Sun, Jul 31, 2011 at 8:16 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
> C++ and Java memory models impose restrictions for locks and unlocks,
> such as a thread that releases a lock must acquired the lock, or the
> number of locks must be larger than the number of unlocks in the same
> thread... for enabling some optimizations, for example, simplifying
> trylocks (http://www.hpl.hp.com/techreports/2008/HPL-2008-56.html),
> and moving some instructions inside lock acquires
> (http://www.hpl.hp.com/techreports/2005/HPL-2005-217R1.html).  What is
> the rationale that the LLVM memory model ignores such restrictions?

The LLVM memory model doesn't include locks at all, so it can't
include restrictions about them. One would implement locks, whether
C++0x, posix, or something else, using the atomic instructions in
Eli's patches, along with syscalls like futex or kqueue.

C++0x's restrictions on locks allow an implementor to choose cheaper
LLVM instructions than they'd otherwise have to. For example, the fact
that try_lock is allowed to fail spuriously allows lock and try_lock
to be implemented with acquire cmpxchg instructions rather than
acq_rel cmpxchg instructions.

The current cmpxchg instruction still leaves a small amount of
performance on the table by having only a single ordering argument,
rather than the two arguments that C++0x takes. In the case of
try_lock, I expect this to manifest as an unnecessary fence on the
failing path on ARM and PPC. Only time will tell whether this matters
in practice, but if it does matter, I expect it to be straightforward
to add the second argument.

Jeffrey