[LLVMdev] Proposal for atomic and synchronization instructions
torvald at wwwse.inf.tu-dresden.de
Mon Jul 9 11:11:08 CDT 2007
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.
TAS and CAS are _not_ theoretically equivalent. TAS is weaker because it can
solve consensus in a nonblocking way only for 2 threads (it has consensus
number 2), whereas CAS can solve consensus for any number of threads
(infinite consensus number).
"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?
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
What are the reasons because of which you picked the Load/Store model for
barriers and not some other kind (e.g., acquire/release/...)?
Did you have a look at the atomic_ops project?
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).
On Monday 09 July 2007 08:39, Chandler Carruth wrote:
> After a fair amount of research and work, I have put together a
> concrete proposal for LLVM representations of atomic operations and
> synchronization constructs. These aim to provide the minimal
> functionality in the IR for representing the hardware constructs that
> threading libraries and parallel programming rely on.
> While I am no expert on the various architectures, I've done my best
> at providing base-line implementations for each instruction. I am sure
> these will need tweaking and fixing, but should provide a very good
> starting point for the targets.
> Comments are more than welcome, especially suggestions for
> improvement. I hope this provides a sound background and a good
> starting place for bringing these features to LLVM. Many thanks also
> go to Reid who has helped tremendously with putting this together, and
> several of the people at Aerospace who helped in the research phase.
> -Chandler Carruth
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the LLVMdev