[LLVMdev] Proposal for atomic and synchronization instructions

Scott Michel scottm at rushg.aero.org
Mon Jul 9 10:33:28 PDT 2007


Torvald Riegel wrote:
> Hi,
> 
> I'd like to see support for something like this. I have some comments, and I 
> think there is existing work that you can reuse.

"reuse within the compiler."

> "While the processor may spin and attempt the atomic operation more than once 
> before it is successful, research indicates this is extremely uncommon."
> I don't understand this sentence, what do you mean?

I'm not sure I can pinpoint the paper from which the statement is based,
but I seem to recall something similar in the original LL-SC papers
(Maurice Herlihy, DEC Western Research Labs?) It's a foundation for
lock-free algorithms.

> You probably don't need to require CAS (compare-and-set) to return the 
> previous value (I think some architectures don't), but just return a boolean 
> value (success/failure).

compare and swap?

> What are the reasons because of which you picked the Load/Store model for 
> barriers and not some other kind (e.g., acquire/release/...)?

Chandler looked at what the various current LLVM architectures and
summarized what he found. What he found are the memory barriers that the
various processors support.

> Did you have a look at the atomic_ops project?
> http://www.hpl.hp.com/research/linux/atomic_ops/
> It already has implementations for several architectures and several 
> compilers. It uses a different consistency model (different set of 
> constraints for operations) and groups necessary memory barriers with 
> instructions (helpful on some architectures). It supports a few more 
> operations. The author (Hans Boehm) seems to also be active in the area of 
> C/C++ memory models (or some support for this).

LLVM doesn't emit external library calls -- there is no "-lllvm" to
which programs have to link, so adding an atomic operation library is
likely to be a non-starter. LLVM is interested in emitting instructions
to make atomic operations (and higher level concurrency primitives)
possible, which is why Chandler's work is usefully important.


-scooter



More information about the llvm-dev mailing list