similar to: [LLVMdev] Proposal for atomic and synchronization instructions

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

Hello, This is the second major revision of the atomic proposal for LLVM. I will try and give a brief overview of the motivating changes, but a greater portion of the text has changed, along with some changes to the proposed additions. http://chandlerc.net/llvm_atomics.html - The proposal has been rewritten to better delineate the goals and purposes of LLVM, and these additions to LLVM. The why

On 7/9/07, Andrew Lenharth <andrewl at lenharth.org> wrote: > Poor alpha, no code examples or entries in your tables. But that said, it uses a load-locked, store-conditional and has various memory barriers which are sufficient to implement all your proposal. Andrew > On 7/9/07, Chandler Carruth <chandlerc at gmail.com> wrote: > > Hello, > > > > After a fair

Here are some comments, quotes are from the draft. > an operation based constraint cannot guard other operations I think constraints associated with a particular instruction usually apply to this instruction and previous/subsequent instructions, so this wouldn't be true. This is the case in the atomic_ops model, and also on ia64 I think. > The single instruction constraints can,

On 7/12/07, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > Here are some comments, quotes are from the draft. > > > an operation based constraint cannot guard other operations > > I think constraints associated with a particular instruction usually apply > to this instruction and previous/subsequent instructions, so this wouldn't > be true. This is the

Poor alpha, no code examples or entries in your tables. Andrew On 7/9/07, Chandler Carruth <chandlerc at gmail.com> 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

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? > > > > I'm not sure I can pinpoint the paper from which the statement is based, > > but I seem to recall something

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

On 7/9/07, John Criswell <criswell at cs.uiuc.edu> wrote: > 1) You may want to consider adding atomic load-<bitwise operation>-store > instructions in addition to load-<add/subtract> instructions. The Linux > kernel uses these for atomic bit setting/clearing, and on many systems > they can be implemented more efficiently using special assembly > instructions.

On Monday 09 July 2007 19:33, Scott Michel wrote: > 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." within the LLVM compiler framework, to be precise. > > > "While the processor may

That is good to hear. The lack of Alpha was purely a lack of time/knowledge of the architecture on my part, hopefully I can start learning some more about how it functions. If you send me either a pointer to appropriate documentation I would be happy to add appropriate information to the page. If you can provide implementations, it would save time, but I don't mind doing a fair portion of the

Torvald Riegel wrote: > On Monday 09 July 2007 19:33, Scott Michel wrote: >> 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." > > within the LLVM compiler framework, to be

On Tuesday 10 July 2007 01:38, Scott Michel wrote: > As Chandler pointed out, LL/SC isn't blocking. It belongs to the > optimistic concurrency class of constructs. One of the earliest papers > (IIRC, the first paper) on LL/SC was: > > Herlihy, M. 1993. A methodology for implementing highly concurrent data > objects. ACM Trans. Program. Lang. Syst. 15, 5 (Nov. 1993), 745-770.

Torvald Riegel wrote: > First of all, I know LL/SC. Did I say it's equivalent to get-and-set? No. > So what are you trying to say, why is the paragraph in the proposal? You > seem to be speculating about architectures in general in one paragraph. > IMHO, I wouldn't try that, because I would have to be either imprecise or > don't state anything new. I was rebutting

On Mon, Jan 4, 2010 at 8:43 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote: >> Hi, thanks everyone for all the comments. I think maybe I wasn't clear that >> I *only* care about atomicity w.r.t. a signal handler interruption in the >> same thread, *not* across threads. Therefore,

On Tue, 10 Jul 2007, Scott Michel wrote: >> The idea is to review the atomic_ops model, and if it makes sense, just >> reuse it. (e.g., atomic_ops seems to have (basic?) support for Alpha). > > atomic_ops may have interesting ideas on how Chandler might proceed and > implement, but using its code is very unlikely. I think that Torvald's point here is that the

On Jan 4, 2010, at 4:35 AM, Chandler Carruth wrote: > Responding to the original email... > > On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: >> In working on an LLVM backend for SBCL (a lisp compiler), there are >> certain sequences of code that must be atomic with regards to async >> signals. > > Can you define exactly what

On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote: > Hi, thanks everyone for all the comments. I think maybe I wasn't clear that > I *only* care about atomicity w.r.t. a signal handler interruption in the > same thread, *not* across threads. Therefore, many of the problems of > cross-CPU atomicity are not relevant. The signal handler gets invoked via

Hi all, Although [smp_]read_barrier_depends() became part of READ_ONCE() in commit 76ebbe78f739 ("locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()"), it still limps on in the Linux memory model with the sinister hope of attracting innocent new users so that it becomes impossible to remove altogether. Let's strike before it's too late: there's only