jaredhoberock
commented
9 years ago Hi Phil, The best way to voice these kinds of concerns is to submit your proposal as a paper and present it at a face-to-face meeting of the C++ standardization committee.
The inability to create user-defined execution policies is a known limitation of version 1 of the Parallelism TS. It's too late to change the technical content of v1 of the TS at this stage. If execution policies are enhanced in version 2 of the TS (it seems likely), then I imagine we'd want to address this feature.
In the meantime, please feel encouraged to become an implementor of version 1 of the Parallelism TS so that the community gains implementation experience :-)
(If a GitHub issue is the wrong forum for voicing this, please point me in a more suitable direction and close this report)
I work on the C++-based Charm++ parallel programming model and runtime system. We'd like to provide parallel implementations of various standard algorithms, as described in N4312. In doing so, we want those implementations to be at least as portable as our system itself, in terms of compiler, OS, and architecture targets.
However, the text in section 2.3 paragraph 2 limits the definition of Execution Policies to implementors, and 4.1.3 paragraph 3 excludes definitions that aren't section 2.3 Execution Policies from being considered for overload. Obviously, an implementor could define how third-party policies can interface with their particular implementation, but that would sharply limit portability.
This seems like an area in which there is substantial room for third-party experimentation and ultimately diverse product offerings, outside the vendors and open-source projects that produce whole implementations of the compiler and standard library. It would benefit users if they could access those third-party implementations compatibly with the standard versions - i.e. include the appropriate headers, and choose the execution policy corresponding to the desired implementation, possibly dynamically.
I don't have an immediate technical proposal on how to provide for this flexibility, but I am willing to work with the group to figure one out. I tried to find the discussion notes from the recent Urbana meeting, since the editor's report says this wording was adopted there, but couldn't find it - maybe they're just not posted yet?