Do concurrent agents support other control-flow patterns besides barriers?

[Dannnno]

For example, OpenMP provides directives like critical, ordered, master, and single. I'm not aware of these (or similar) being provided by the existing concurrent_agent, and they're somewhat hard to do in a portable manner. Is it worthwhile adding these (and potentially others)? And if so, is there any value in having different types of concurrent agents? As an example, there might be an omp::concurrent_agent whose versions of these functions simply take in lambdas and execute them in the appropriate directive, while the default concurrent_agent would have to use an OpenMP independent version of each of them.

[jaredhoberock]

There may be value in different types of concurrent agents, but only as last resort where no other implementation strategy is possible, I think. The entire purpose of the agent types is to enable portability when writing kernels. For example, the same concurrent_agent type is usable in both CPU and GPU programs.

For the features you mention, maybe it would be possible to implement them externally to concurrent_agent. My guess is that concurrent_agent's barrier is sufficient to implement all of the control structures you mention.

For example, it's possible to implement a critical section using .elect() & .wait():

if(self.elect())
{
  // do critical section stuff
  ...
}
self.wait();

It might be useful to wrap up the implementations of some of the more common control structures into functions, and it would be interesting to investigate any performance differences between pure OpenMP implementations of these directives versus what one could emulate with concurrent_agent. For example, we noted that an ad hoc reduction implemented in Agency happened to out-perform OpenMP's native reduction directive. So it's not clear that native OpenMP directives always imply an efficiency advantage.

Another issue with the OpenMP directives is that the programmer is constrained by where directives are allowed to be used. Some of the directives (like ordered) must be applied to the for loop encapsulating the execution. However, the programmer would request the ordered section at a code location distant from the originating for loop. So my guess is that the way that some of the OpenMP features are requested by directives probably isn't compatible with the way Agency is organized.