This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
Section: 33.3.1 [thread.stoptoken.intro] Status: New Submitter: Brian Bi Opened: 2023-04-16 Last modified: 2023-04-16
Priority: 3
View all issues with New status.
Discussion:
The first sentence of 33.3.1 [thread.stoptoken.intro]/5 says:
Calls to the functions request_stop, stop_requested, and stop_possible do not introduce data races.
This could be read as saying that if you have a program that doesn't contain data races, and you change it by adding a call to any of these three functions, such a change does not "introduce" data races into the program. In other words, it could be read as saying that these three functions don't race with any other member functions on the same stop_token or stop_source object.
I'm guessing the actual intended meaning is that calls to these three functions do not race with each other, because it would be more expensive if concurrent calls with stop_token::operator= were also required to not race. (Also, none of these functions can avoid racing with the destructor.)[2023-05-24; Reflector poll]
Set priority to 3 after reflector poll.
"What about get_token? operator==?"
"Other functions like get_stop_token can also be called
concurrently. I think the text is actually correct."
Proposed resolution:
This wording is relative to N4944.
Modify 33.3.1 [thread.stoptoken.intro] as indicated:
-5- Calls to the functions request_stop, stop_requested, and stop_possible do not introduce data races with each other. A call to request_stop that returns true synchronizes with a call to stop_requested on an associated stop_token or stop_source object that returns true. Registration of a callback synchronizes with the invocation of that callback.