OpenMP® Forum

Discussion on the OpenMP specification run by the OpenMP ARB. OpenMP and the OpenMP logo are registered trademarks of the OpenMP Architecture Review Board in the United States and other countries. All rights reserved.

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 + 3as invalid given that the + in expr 2 + 3 has smaller precedence than * and thus x = x * 2 + 3 isn't mathematically equivalentto 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 precedenceof 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 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 precedenceof 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?

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.

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

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.

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.