std::condition_variable:: wait_until

wait_until entraîne le blocage du thread actuel jusqu'à ce que la variable de condition soit notifiée, que le point temporel spécifié soit atteint, ou qu'un réveil intempestif se produise. pred peut être optionnellement fourni pour détecter les réveils intempestifs.

Immédiatement après que wait_until retourne, lock. owns_lock ( ) est true , et lock. mutex ( ) est verrouillé par le thread appelant. Si ces postconditions ne peuvent être satisfaites ^[1] , appelle std::terminate .

Si l'une des conditions suivantes est satisfaite, le comportement est indéfini :

• lock. owns_lock ( ) est false .
• lock. mutex ( ) n'est pas verrouillé par le thread appelant.
• Si d'autres threads attendent également sur * this , lock. mutex ( ) est différent du mutex déverrouillé par les fonctions d'attente ( wait , wait_for et wait_until ) appelées sur * this par ces threads.

1. ↑ Cela peut se produire si le nouveau verrouillage du mutex lève une exception.

Paramètres

Valeur de retour

Exceptions

Notes

La norme recommande que l'horloge associée à abs_time soit utilisée pour mesurer le temps ; cette horloge n'est pas requise d'être une horloge monotone. Il n'y a aucune garantie concernant le comportement de cette fonction si l'horloge est ajustée de manière discontinue, mais les implémentations existantes convertissent abs_time de Clock vers std::chrono::system_clock et délèguent à pthread_cond_timedwait POSIX afin que l'attente prenne en compte les ajustements de l'horloge système, mais pas ceux de l'horloge Clock fournie par l'utilisateur. Dans tous les cas, la fonction peut également attendre au-delà du moment où abs_time est atteint en raison de délais de planification ou de contention des ressources.

Même si l'horloge utilisée est std::chrono::steady_clock ou une autre horloge monotone, un ajustement de l'horloge système peut provoquer un réveil intempestif.

Les effets de notify_one() / notify_all() et chacune des trois parties atomiques de wait() / wait_for() / wait_until() (déverrouillage+attente, réveil et verrouillage) se produisent dans un ordre total unique qui peut être considéré comme l'ordre de modification d'une variable atomique : cet ordre est spécifique à cette variable conditionnelle individuelle. Cela rend impossible, par exemple, que notify_one() soit retardé et débloque un thread qui a commencé à attendre juste après l'appel à notify_one() ait été effectué.

Exemple

#include <chrono>
#include <condition_variable>
#include <iostream>
#include <thread>
std::condition_variable cv;
std::mutex cv_m; // Ce mutex est utilisé à trois fins :
                 // 1) synchroniser les accès à i
                 // 2) synchroniser les accès à std::cerr
                 // 3) pour la variable de condition cv
int i = 0;
void waits()
{
    std::unique_lock<std::mutex> lk(cv_m);
    std::cerr << "En attente... \n";
    cv.wait(lk, []{ return i == 1; });
    std::cerr << "...fin de l'attente. i == 1\n";
}
void signals()
{
    std::this_thread::sleep_for(std::chrono::seconds(1));
    {
        std::lock_guard<std::mutex> lk(cv_m);
        std::cerr << "Notification...\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 << "Nouvelle notification...\n";
    }
    cv.notify_all();
}
int main()
{
    std::thread t1(waits), t2(waits), t3(waits), t4(signals);
    t1.join(); 
    t2.join(); 
    t3.join();
    t4.join();
}

En attente...
En attente...
En attente...
Notification...
Nouvelle notification...
...fin de l'attente. i == 1
...fin de l'attente. i == 1
...fin de l'attente. i == 1

Rapports de défauts

Les rapports de défauts modifiant le comportement suivants ont été appliqués rétroactivement aux normes C++ précédemment publiées.

Voir aussi