CP013: Support querying the load factor of an execution context

[AerialMantis]

There was feedback from Jacksonville that it would be useful to be able to query the load factor of an execution context, as to make a decision based on the current load of different contexts.

[hcedwar]

cut&paste from email thread:

I have been interpreting "concurrency" as a guaranteed-not-to-exceed upper bound, not a promise-to-provide. When accounting for contention in an algorithm the guaranteed-not-to-exceed is the thing.

The intention for D0796r2 was that concurrency() would return the maximum number of threads of execution associated with this execution resource, so guaranteed-not-to-exceed. But you raise a good point here that an execution resource may have a potential concurrency of N but an execution resource may not be able to guarantee that N threads of execution will always be capable of making forward progress at once. I agree that the latter is a property which is more associated with an execution context than an execution resource; the resource reflecting the hardware potential and the context reflecting whats actually available.

I think these two properties should be separated, or at least we need to clarify that concurrency() only states the maximum potential concurrency of the resource. We could also introduce a member function to the context which provides the current concurrency guarantee, i.e. the number of threads of execution currently available. I believe this is related to something which was requested at Jacksonville; the ability to query an execution context for it's current load factor

[hcedwar]

I don't believe a current concurrency guarantee is feasible. The number of concurrency resources utilized (or conversely not-utilized) at some instant during the call to the measuring function is probably the best that could be done.