DO PARALLEL

[rouson]

Given the well-documented issues that can block parallelizing do concurrent safely in some cases and the fact that proposed fixes might invalidate currently conforming codes, it seems worthwhile to consider making a third pass at loop level parallelism. A new feature might take the form of a do parallel that is very similar to do concurrent in syntax and semantics (to minimize the work for implementors and to simplify application refactoring), but would have additional constraints designed to guarantee that the new construct is parallelizable.

[certik]

At the very least this feature must be figured out. Once it is ready, we can perhaps try convincing the committee/community to just name it do concurrent (and break backwards compatibility slightly); otherwise we keep the namedo parallel.

[klausler]

For the purposes of fixing DO CONCURRENT, the necessary change is to the default localization semantics only -- namely, default localization must apply only to objects that could appear explicitly in a LOCAL() clause. That in itself doesn't seem to justify a new keyword with all the consequent confusion to users. However, if J3 takes up some other proposals that extend the capabilities of DO CONCURRENT with things like atomic operations, the current "each iteration is fully executed in some unspecified sequential order" semantics will also require rethinking, and so maybe a DO PARALLEL will be necessary anyway so that a tasking model and memory model can be reasonably defined. (Atomics in the current DO CONCURRENT iteration semantics would imply behavior that wouldn't allow for interleaved accesses from multiple iterations.)

[PierreChezGeGe]

If a do parallel construct was defined in order to fix the limitations of do concurrent, couldn't do concurrent be just deprecated?