This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Implement `std::condition_variable_any::wait[_for/until]` overloads that take `stop_token`
ClosedPublic

Authored by huixie90 on Jun 21 2023, 9:40 AM.

Details

Diff Detail

Event Timeline

huixie90 created this revision.Jun 21 2023, 9:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 21 2023, 9:40 AM
huixie90 requested review of this revision.Jun 21 2023, 9:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 21 2023, 9:40 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript

In general looks good. I have some minor comments. I think it would be good to keep track how often predicates are called and whether that matches the (minimal) expectation. For example when a stop_requested() == true the predicate is called exactly one time.

libcxx/include/condition_variable
106

Can you align the // since C++20 ?

319
328
libcxx/test/std/thread/thread.condition/thread.condition.condvarany/wait_for_token_pred.pass.cpp
96

This is our typical code style.

135

I wonder here and at other places whether 2 ms is long enough.
Are we sure this is changed after the wait_for is really in it's loop? Or can the flag be set before entering the loop.

Would it make sense to validate how often the predicate is executed? When it's less than 2 the loop was executed 0 times.

libcxx/test/std/thread/thread.condition/thread.condition.condvarany/wait_token_pred.pass.cpp
43

Please include <concepts>.

ldionne commandeered this revision.Jul 7 2023, 6:17 AM
ldionne edited reviewers, added: huixie90; removed: ldionne.

Commandeering per discussion w/ Hui.

libcxx/include/condition_variable
95

Let's mark this as experimental.

huixie90 commandeered this revision.Sep 15 2023, 1:24 AM
huixie90 edited reviewers, added: ldionne; removed: huixie90.
huixie90 updated this revision to Diff 556846.Sep 15 2023, 4:19 AM
huixie90 marked 3 inline comments as done.

address feedback rebase

huixie90 updated this revision to Diff 556876.Sep 15 2023, 12:21 PM
huixie90 marked an inline comment as done.

CI

huixie90 added inline comments.Sep 16 2023, 2:41 AM
libcxx/include/condition_variable
319

this is a member function call . not std::wait_until

328

this is a member function call, not std::wait_until

huixie90 updated this revision to Diff 556913.Sep 17 2023, 7:27 AM

guard stop_token headers with no thread macro

ldionne added inline comments.Sep 19 2023, 8:11 AM
libcxx/test/std/thread/thread.condition/thread.condition.condvarany/wait_for_token_pred.pass.cpp
135

If the thread creation is really slow, this test could be vacuous (it would test the same as the test that does request_stop() before we wait_for). Would it make sense to instead do something like:

auto thread = support::make_test_thread([&]() {
    // wait until we're ready
    some_atomic.wait(...);
    ss.request_stop();

    while (!done) {
        cv.notify_all();
        std::this_thread::sleep_for(2ms);
      }
});

std::same_as<bool> auto r = cv.wait_for(lock, ss.get_token(), 1h, [&]() {
  some_atomic.notify_all(); // here signal that we're ready for the other thread to request a stop
  return false;
});
assert(!r);
done = true;
thread.join();

Does this make sense at all? That way the pred will be the one to trigger the fact that we request_stop() on the other thread. Would that be more robust?

libcxx/test/std/thread/thread.condition/thread.condition.condvarany/wait_token_pred.pass.cpp
80

Whatever we do for the other test we should do here too.

libcxx/test/std/thread/thread.condition/thread.condition.condvarany/wait_until_token_pred.pass.cpp
130

And here.

huixie90 updated this revision to Diff 557207.Sep 21 2023, 2:58 PM
huixie90 marked 6 inline comments as done.

address feedback

ldionne accepted this revision.Sep 27 2023, 8:44 AM

LGTM with minor nitpick. You can ignore the CI failures since they are unrelated and have been fixed since then. Thanks!

libcxx/docs/Status/Cxx20.rst
51 ↗(On Diff #557207)
This revision is now accepted and ready to land.Sep 27 2023, 8:44 AM
This revision was landed with ongoing or failed builds.Sep 29 2023, 5:50 AM
This revision was automatically updated to reflect the committed changes.