specify the forward progress guarantee made by run_loop's run member function #293
Conversation
ericniebler
requested review from
brycelelbach,
griwes,
mjgarland and
LeeHowes
| @@ -4467,6 +4467,8 @@ from the operation before the operation completes. | |||
|
|
|||
| 2. <i>Synchronization:</i> This operation synchronizes with all `pop_front` operations on this object. | |||
|
|
|||
| 3. <i>Remarks:</i> If the thread of execution calling `run()` guarantees concurrent or parallel forward progress, then it guarantees parallel forward progress until `run()` returns; otherwise, it guarantees weakly parallel forward progress. | |||
There was a problem hiding this comment.
then it guarantees parallel forward progress until
maybe:
then tasks execute from the queue with parallel forward progress until run() returns; otherwise tasks execute with weakly parallel forward progress until run() returns.
I found the "it"s in this text confusing at first.
There was a problem hiding this comment.
@mgarland tells me that when the standard discusses forward progress, it is in the context of threads of execution, not tasks or work.
There was a problem hiding this comment.
Yes, but in this case we surely need to say something about the set of threads of execution being created from the queue. I don't think the text is clear unless we have some name for the things in the context's queue, and a way to describe those things being turned into threads of execution with parallel FP, and then executing with parallel FP.
Alternatively we could say in the add operation that it creates a thread of execution in the queue, and say here that the queue's threads of execution will execute in-order with parallel FP?
I can see though that I may have misunderstood what you intended with this wording. Were you simply trying to describe the duration over which parallel FP is guaranteed? Now that I reread it I see that interpretation instead.
There was a problem hiding this comment.
Yes that's what I was trying to say: that for the duration of run(), if the thread calling run() has concurrent forward progress, it is demoted to parallel.
There was a problem hiding this comment.
It would be nice if we could specify everything using only a single term (e.g., "thread of execution"). However, in looking more closely at the current standard wording, I'm not sure that's feasible.
The definition of "thread of execution" says that it is implementation-defined whether more than one can exist in freestanding implementations [intro.multithread.general]. I think the current wording presumes a direct correspondence between "threads of execution" and "threads".
Section [thread.req.lockable.general] introduces the concept "execution agent", which we could reuse for naming the unit of work.
There was a problem hiding this comment.
Regarding the wording of the guarantee, what you've written is similar to the current wording on the semantics of the parallel execution policy. From [algorithms.parallel.exec], paragraph 6:
If the threads of execution created by
threadorjthreadprovide concurrent forward progress guarantees, then a thread of execution implicitly created by the library will provide parallel forward progress guarantees; otherwise, the provided forward progress guarantee is implementation-defined. Any such invocations executing in the same thread of execution are indeterminately sequenced with respect to each other.
It only guarantees parallel forward progress if thread provides concurrent guarantees. I don't recall why it requires concurrent and not concurrent or parallel.
There was a problem hiding this comment.
I don't recall why it requires concurrent and not concurrent or parallel.
Yes, that isn't clear... if the thread started already then it will continue under parallel rules as well.
Yes that's what I was trying to say: that for the duration of run(), if the thread calling run() has concurrent forward progress, it is demoted to parallel.
I don't think that is right, though. The calling agent has concurrent FP whatever happens doesn't it? The point here surely is that the FP of the agents waiting in the execution context's queue have parallel FP. We can only derive parallel from concurrent (or indeed from parallel) because those agents haven't started yet. The main agent already has started so it isn't really demoted at all, it just is what it is.
Unless this is simply the only way to word that intention, but it strikes me as odd. What michael quotes seems to me to say something a little different.
There was a problem hiding this comment.
I don't think that is right, though. The calling agent has concurrent FP whatever happens doesn't it?
<sigh> I've gotten myself confused again. Since the execution of run() involves blocking for some condition to be satisfied by another thread (work is added to the queue, or another thread calls finish()), and since we can't guarantee that that will ever happen, it's possible that run() will never make progress. So doesn't that mean that the thread of execution calling run() has weakly parallel FP until it returns?
|
Moved to brycelelbach/wg21_p2300_execution#18 |
No description provided.