Statements knowing their atomicity in the tree?

[LonelyCat124]

One common theme throughout NG-Arch is that PSyclone is quite limited with how to apply parallelism to sections that need atomicity.

The current approach would be (as I remember/understand):

1. Apply the relevant parallel transformation with force=True.
2. Add any XXXAtomicDirective to the problematic statements.

The only way to check for a statements atomicity at the moment, would be to check if they have an ancestor of a specific set of types in a transformation, but maybe adding a is_atomic function onto a statement could help with this behaviour. This is of course complicated due to e.g.

!$omp atomic read
b[i] = x

is atomic w.r.t x but not b, and would get more complicated if we were to support capture. Maybe it would need to have multiple return values (e.g. lhs and rhs atomic relevance, or read/write/update)

What I would then suggest, is reversing the order of things - user applies XXXAtomicDirectives to the statements they expect to need atomics, and then can just use apply with force=False and the dependency analysis/parallel checking code can look at the relevant atomics and account for them during analysis.

This would also make adding more mutex-style operations (such as omp critical) easier, though it is a heavier initial cost.

@sergisiso @arporter @hiker any thoughts on this approach/its feasibility vs what we have now?

[sergisiso]

I agree with this approach.

My only worry is what happens if the atomic is added and then the parallel transformation fails (as we typically apply it everywhere expecting it to fail sometimes). Are atomics outside parallel regions a problem?

What I was contemplating is an option in the transformation that would add the atomic when the dependency analysis reported a race condition, but I am unsure if we can do that safely. So maybe adding it before manually (the responsibility is still for the script writer) and just check in the transformation is a good middle step.

The only way to check for a statements atomicity at the moment, would be to check if they have an ancestor of a specific set of types in a transformation, but maybe adding a is_atomic function onto a statement could help with this behaviour.

I think the "is_atomic" has to be added to Reference, not Statement. As it can support more complicated logic to check if the directive refers to itself.

[LonelyCat124]

What I was contemplating is an option in the transformation that would add the atomic when the dependency analysis reported a race condition, but I am unsure if we can do that safely. So maybe adding it before manually (the responsibility is still for the script writer) and just check in the transformation is a good middle step.

I suspect we can use some of the reduction logic for some atomics, but I doubt we can easily capture them all, and I think this logic might simplify things too.