[LLVMdev] Proposal for atomic and synchronization instructions

[Torvald Riegel]

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.

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 
value (success/failure).

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?
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).


Torvald

On Monday 09 July 2007 08:39, Chandler Carruth wrote:
> Hello,
>
> 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.
>
> http://chandlerc.net/llvm_atomics.html
>
> 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
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev