Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

specify the forward progress guarantee made by run_loop's run member function #293

Closed
wants to merge 1 commit into from
Closed

specify the forward progress guarantee made by run_loop's run member function #293

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion std_execution.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4423,7 +4423,7 @@ from the operation before the operation completes.
<i>run-loop-opstate-base</i>* run_loop::pop_front();
</pre>

1. <i>Effects:</i> Waits until one of the following conditions is `true`:
1. <i>Effects:</i> Blocks ([defns.block]) until one of the following conditions is `true`:

* <i>count</i> is `0` and <i>state</i> is <i>finishing</i>, in which case `pop_front` returns `nullptr`; or

Expand Down Expand Up @@ -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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mgarland tells me that when the standard discusses forward progress, it is in the context of threads of execution, not tasks or work.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 thread or jthread provide 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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?


## Coroutine utilities <b>[execution.coro_utils]</b> ## {#spec-execution.coro_utils}

### `execution::as_awaitable` <b>[execution.coro_utils.as_awaitable]</b> ### {#spec-execution.coro_utils.as_awaitable}
Expand Down