new C/C++ atomic update and capture forms

[jakub]

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?
http://openmp.org/forum/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?

[aduran]

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?
http://openmp.org/forum/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.

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.

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.

[jakub]

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.

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.

[aduran]

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

[jakub]

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

[aduran]

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.

[jakub]

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.