new C/C++ atomic update and capture forms

Discuss the OpenMP 3.1 API Specifications with the OpenMP Arch. Review Board. (Read Only)

new C/C++ atomic update and capture forms

Postby jakub » Tue Jul 12, 2011 3:29 am

I see that the C/C++ atomic update and capture forms have changed substantially from the draft (unfortunately
there is no atomic swap form, has that been rejected forever or will it be considered for OpenMP 4.0?
viewtopic.php?f=9&t=1081#p4416 ).

The addition of x = x binop expr forms in addition to x binop= expr was IMHO unnecessary and will complicate parsing it.
Furthermore, unlike the Fortran descriptions there is no wording about operator precedence which would rule say
#pragma omp atomic update
x = x * 2 + 3
as invalid given that the + in expr 2 + 3 has smaller precedence than * and thus x = x * 2 + 3 isn't mathematically equivalent
to x = x * (2 + 3). Shall I just assume this is an omission of the new standard and code it as if
"The operators in expr must have precedence equal to or greater than the precedence
of operator, x operator expr must be mathematically equivalent to x operator (expr)."
was stated even for C for the x = x binop expr forms?

x = expr binop x forms weren't added, was that intentional (that would even further complicate parsing)?
And, for the one statement #pragma omp atomic capture form the v = x = x binop expr; form wasn't added, was that intentional?
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Re: new C/C++ atomic update and capture forms

Postby aduran » Thu Jul 28, 2011 4:40 am

jakub wrote:I see that the C/C++ atomic update and capture forms have changed substantially from the draft (unfortunately
there is no atomic swap form, has that been rejected forever or will it be considered for OpenMP 4.0?
viewtopic.php?f=9&t=1081#p4416 ).


The swap form was rejected because some architectures do not have support for it and vendors expressed concerns about the performance implications of that. We'll revisit it for 4.0 and see if an agreement can be reached about it.

jakub wrote: Shall I just assume this is an omission of the new standard and code it as if
"The operators in expr must have precedence equal to or greater than the precedence
of operator, x operator expr must be mathematically equivalent to x operator (expr)."
was stated even for C for the x = x binop expr forms?


Yes, you're right. A sentence like the one in Fortran is missing. We'll add the setence in the next release.

jakub wrote: x = expr binop x forms weren't added, was that intentional (that would even further complicate parsing)? And, for the one statement #pragma omp atomic capture form the v = x = x binop expr; form wasn't added, was that intentional?


Yes, those two were intentionally omitted.
aduran
 
Posts: 12
Joined: Wed Oct 24, 2007 8:33 am
Location: Barcelona, Spain

Re: new C/C++ atomic update and capture forms

Postby jakub » Thu Jul 28, 2011 8:12 am

aduran wrote:The swap form was rejected because some architectures do not have support for it and vendors expressed concerns about the performance implications of that. We'll revisit it for 4.0 and see if an agreement can be reached about it.


Which architectures are that? Just curious? Because even for current #pragma omp atomic support you generally need a full compare and swap instruction, while some architectures have say specialized atomic increment/decrement etc. insns, e.g. for float addition full compare and swap is needed. And with a compare and swap instruction the swapping is easily implementable (read non-atomically old value, compare and swap the old value to the new value, in a loop (perhaps for the second iteration and on use as old value whatever the atomic insn returned was currently in the memory instead of reading it again non-atomically). And of course several architectures have special instructions for the atomic swap.

aduran wrote:Yes, you're right. A sentence like the one in Fortran is missing. We'll add the setence in the next release.


Thanks, we'll implement it that way as if it was there.
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Re: new C/C++ atomic update and capture forms

Postby aduran » Fri Jul 29, 2011 1:02 am

jakub wrote:Which architectures are that? Just curious?


Architectures that are based on load-linked/store-conditional instructions (powerpc, arm, mips, ...) do not rely on a compare-an-swap instruction for atomics.

Certainly swap semantics can be implemented as well with LL/SC but some people expressed concerns that we didn't have the time to explore before the release. I'm hopeful we'll sort it out for the next one :)
aduran
 
Posts: 12
Joined: Wed Oct 24, 2007 8:33 am
Location: Barcelona, Spain

Re: new C/C++ atomic update and capture forms

Postby jakub » Fri Jul 29, 2011 3:12 am

aduran wrote:Architectures that are based on load-linked/store-conditional instructions (powerpc, arm, mips, ...) do not rely on a compare-an-swap instruction for atomics.


I considered LL/SC architectures to have a full compare and swap mechanism, while it isn't a single instruction, it is possible to write it using multiple instructions.
And on LL/SC architectures the atomic exchange is usually the shortest possible atomic operation sequence, e.g. on PowerPC:

Code: Select all
1b:   lwarx oldvalreg,0,ptrreg
   stwcx. newvalreg,0,ptrreg
   bne- 0,1b
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Re: new C/C++ atomic update and capture forms

Postby aduran » Fri Jul 29, 2011 5:55 am

jakub wrote:I considered LL/SC architectures to have a full compare and swap mechanism, while it isn't a single instruction, it is possible to write it using multiple instructions.


I personally agree with you that's why I think there's a good possibility it makes to the next release.
aduran
 
Posts: 12
Joined: Wed Oct 24, 2007 8:33 am
Location: Barcelona, Spain

Re: new C/C++ atomic update and capture forms

Postby jakub » Sat Jul 30, 2011 2:56 am

aduran wrote:Yes, you're right. A sentence like the one in Fortran is missing. We'll add the setence in the next release.


Just to be sure, equal precedence would be considered valid for commutative binops and invalid for non-commutative here, right? And with 3 occurrences of x all side-effects would need to be evaluated 3 times.

Code: Select all
#pragma omp atomic capture
  {
    ptr[foo (), 0] = ptr[foo (), 0] + x + y;
    z = ptr[foo (), 0];
  }


I think function calls are the only safe side-effects (plus volatile reads), having e.g. some assignment inside of x lvalue expression with the x = x binop expr form would mean undefined behavior due to no sequence point separating those side-effects.

For non-commutative allowing equal precedence complicates parsing, say if

Code: Select all
#pragma omp atomic update
  x = x - 6 + 7;


would be valid (I hope it isn't), then it couldn't be evaluated as atomically decrement (6 + 7), similarly

Code: Select all
#pragma omp atomic
  x = x / 5 * 2;


If it is worded that x = x binop expr must be mathematically equivalent to x = x binop (expr), then that wording implies it.
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am


Return to OpenMP 3.1 API Specifications

Who is online

Users browsing this forum: No registered users and 1 guest