std::condit...::wait_until(3)

💖 std::condition_variable::wait_until 💖

Okay bestie, so this is literally the std::condition_variable::wait_until page from the C++ Standard Library and it's giving "I block your thread until a specific time point" energy. No cap, it's iconic for timed waits.

---

✨ Synopsis ✨

template< class Clock, class Duration >

std::cv_status
    wait_until( std::unique_lock<std::mutex>& lock,
(1) (since C++11)

                const std::chrono::time_point<Clock, Duration>&
abs_time );
template< class Clock, class Duration, class Predicate >

bool wait_until( std::unique_lock<std::mutex>& lock,
                 const std::chrono::time_point<Clock, Duration>&
(2) (since C++11)
abs_time,

                 Predicate pred );

So wait_until literally causes the current thread to block until the condition variable is notified, the given time point has been reached, or a spurious wakeup occurs. And pred can optionally be provided to detect spurious wakeup — it's giving "I'm checking if you actually woke up for a real reason" vibes.

---

🎀 The Two Overloads 🎀

1) Atomically calls lock.unlock() and blocks on *this. The thread will be unblocked when notify_all() or notify_one() is executed, or abs_time is reached. It may also be unblocked spuriously. When unblocked, calls lock.lock() (possibly blocking on the lock), then returns. Slay, but lowkey it can block again on the re-lock.

2) Equivalent to:

while (!pred())
    if (wait_until(lock, abs_time) == std::cv_status::timeout)
        return pred();
return true;

This overload may be used to ignore spurious awakenings while waiting for a specific condition to become true. It's literally the "keep waiting until your fave condition is true or we time out" vibe check.

If pred() is ill-formed, or the return value of pred() is not convertible to bool (until C++20) decltype(pred()) does not model boolean-testable (since C++20), the program is ill-formed. So bestie, don't mess with the predicate type or it's giving "compiler errors for days."

---

Right after wait_until returns, lock.owns_lock() is true, and lock.mutex() is locked by the calling thread. If these postconditions cannot be satisfied^[1], calls std::terminate. 💀 That's the "you broke the contract, we're ending the program" energy.

If any of the following conditions is satisfied, the behavior is undefined:

• lock.owns_lock() is false.
• lock.mutex() is not locked by the calling thread.
• If some other threads are also waiting on *this, lock.mutex() is different from the mutex unlocked by the waiting functions (wait, wait_for and wait_until) called on *this by those threads.

^[1] This can happen if the re-locking of the mutex throws an exception.

---

🌸 Parameters 🌸

• lock — an lock which must be locked by the calling thread
• abs_time — the time point where waiting expires
• pred — the predicate to check whether the waiting can be completed

---

🦋 Type requirements 🦋

• Predicate must meet the requirements of FunctionObject.

---

💅 Return value 💅

1. std::cv_status::timeout if abs_time has been reached, otherwise std::cv_status::no_timeout.
2. The latest result of pred() before returning to the caller.

---

👑 Exceptions 👑

1. Timeout-related exceptions.
2. Timeout-related exceptions, and any exception thrown by pred.

---

🌈 Notes 🌈

The standard recommends that the clock tied to abs_time be used to measure time; that clock is not required to be a monotonic clock. There are no guarantees regarding the behavior of this function if the clock is adjusted discontinuously, but the existing implementations convert abs_time from Clock to std::chrono::system_clock and delegate to POSIX pthread_cond_timedwait so that the wait honors adjustments to the system clock, but not to the user-provided Clock. In any case, the function also may wait for longer than until after abs_time has been reached due to scheduling or resource contention delays. It's giving "time is a construct and your thread might be late."

Even if the clock in use is std::chrono::steady_clock or another monotonic clock, a system clock adjustment may induce a spurious wakeup. So even your steady clock can't protect you from spurious vibes.

The effects of notify_one()/notify_all() and each of the three atomic parts of wait()/wait_for()/wait_until() (unlock+wait, wakeup, and lock) take place in a single total order that can be viewed as modification order of an atomic variable: the order is specific to this individual condition variable. This makes it impossible for notify_one() to, for example, be delayed and unblock a thread that started waiting just after the call to notify_one() was made. Iykyk — it's the "notifications are synchronized, bestie" moment.

---

⭐ Example ⭐

// Run this code

#include <chrono>
#include <condition_variable>
#include <iostream>
#include <thread>

std::condition_variable cv;
std::mutex cv_m; // This mutex is used for three purposes:
                 // 1) to synchronize accesses to i
                 // 2) to synchronize accesses to std::cerr
                 // 3) for the condition variable cv
int i = 0;

void waits()
{
    std::unique_lock<std::mutex> lk(cv_m);
    std::cerr << "Waiting... \n";
    cv.wait(lk, []{ return i == 1; });
    std::cerr << "...finished waiting. i == 1\n";
}

void signals()
{
    std::this_thread::sleep_for(std::chrono::seconds(1));
    {
        std::lock_guard<std::mutex> lk(cv_m);
        std::cerr << "Notifying...\n";
    }
    cv.notify_all();

    std::this_thread::sleep_for(std::chrono::seconds(1));

    {
        std::lock_guard<std::mutex> lk(cv_m);
        i = 1;
        std::cerr << "Notifying again...\n";
    }
    cv.notify_all();
}

int main()
{
    std::thread t1(waits), t2(waits), t3(waits), t4(signals);
    t1.join();
    t2.join();
    t3.join();
    t4.join();
}

Possible output:

Waiting...
Waiting...
Waiting...
Notifying...
Notifying again...
...finished waiting. i == 1
...finished waiting. i == 1
...finished waiting. i == 1

---

🧚 Defect reports 🧚

The following behavior-changing defect reports were applied retroactively to previously published C++ standards.

• LWG 2093 — Applied to: C++11. Behavior as published: timeout-related exceptions were missing in the specification. Correct behavior: mentions these exceptions.
• LWG 2135 — Applied to: C++11. Behavior as published: the behavior was unclear if lock.lock() throws an exception. Correct behavior: calls std::terminate in this case.

---

💜 See also 💜

• wait — blocks the current thread until the condition variable is awakened (public member function)
• wait_for — blocks the current thread until the condition variable is awakened or after the specified timeout duration (public member function)

---

Hidden category: Pages with unreviewed LWG DR marker

---

Okay bestie, that's the whole page! This is literally from http://cppreference.com and the date on it is 2024.06.10. So next time you're waiting on a condition variable with a timeout, you know exactly what's up. Periodt. 💅✨🫶