[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