Namensräume
Varianten
Aktionen

std::recursive_timed_mutex::try_lock_until

Von cppreference.com
 
 
Bibliothek für nebenläufige Programmierung
Threads
(C++11)
(C++20)
this_thread Namespace
(C++11)
(C++11)
(C++11)
Kooperatives Beenden
Gegenseitiger Ausschluss
(C++11)
Allgemeines Sperrungsmanagement
(C++11)
(C++11)
(C++11)
(C++11)
(C++11)
Bedingungsvariablen
(C++11)
Semaphoren
Latches und Barriers
(C++20)
(C++20)
Futures
(C++11)
(C++11)
(C++11)
(C++11)
Sichere Wiederherstellung
(C++26)
Hazard Pointer
Atomare Typen
(C++11)
(C++20)
Initialisierung von atomaren Typen
(C++11)(veraltet in C++20)
(C++11)(veraltet in C++20)
Speicherordnung
(C++11)(deprecated in C++26)
Freie Funktionen für atomare Operationen
Freie Funktionen für atomare Flags
 
 
template< class Clock, class Duration >
bool try_lock_until( const std::chrono::time_point<Clock, Duration>& timeout_time );
(seit C++11)

Versucht, die Mutex zu sperren. Blockiert, bis die angegebene timeout_time erreicht ist (Timeout) oder die Sperre erworben wird (Besitz der Mutex), je nachdem, was zuerst eintritt. Bei erfolgreichem Erwerb der Sperre wird true zurückgegeben, andernfalls wird false zurückgegeben.

Wenn timeout_time bereits verstrichen ist, verhält sich diese Funktion wie try_lock().

Clock muss die Clock-Anforderungen erfüllen.Das Programm ist schlecht geformt, wenn std::chrono::is_clock_v<Clock> false ist.(seit C++20)

Der Standard empfiehlt, die an timeout_time gebundene Uhr zu verwenden, in welchem Fall Anpassungen der Uhr berücksichtigt werden können. Somit kann die Dauer des Blocks mehr oder weniger als timeout_time - Clock::now() zum Zeitpunkt des Aufrufs betragen, abhängig von der Richtung der Anpassung und ob sie von der Implementierung berücksichtigt wird. Die Funktion kann auch über timeout_time hinaus blockieren, aufgrund von Prozessplanung oder Ressourcenkonfliktverzögerungen.

Wie bei try_lock() darf diese Funktion fehlschlagen und false zurückgeben, auch wenn die Mutex zu keinem Zeitpunkt vor timeout_time von einem anderen Thread gesperrt wurde.

Eine vorherige unlock()-Operation auf derselben Mutex *synchronisiert sich mit* (wie in std::memory_order definiert) dieser Operation, wenn sie true zurückgibt.

Ein Thread kann try_lock_until wiederholt auf einer rekursiven Mutex aufrufen. Erfolgreiche Aufrufe von try_lock_until erhöhen den Besitzzähler: Die Mutex wird erst freigegeben, nachdem der Thread eine entsprechende Anzahl von Aufrufen von unlock durchgeführt hat.

Die maximale Anzahl von Besitzebenen ist nicht spezifiziert. Ein Aufruf von try_lock_until gibt false zurück, wenn diese Anzahl überschritten wird.

Inhalt

[bearbeiten] Parameter

timeout_time - maximaler Zeitpunkt, bis zu dem blockiert werden soll

[bearbeiten] Rückgabewert

true, wenn die Sperre erfolgreich erworben wurde, andernfalls false.

[bearbeiten] Ausnahmen

Alle Ausnahmen, die von timeout_time ausgelöst werden (Uhren, Zeitpunkte und Zeitspannen, die von der Standardbibliothek bereitgestellt werden, werfen niemals Ausnahmen).

[bearbeiten] Beispiel

Defect reports

Die folgenden Verhaltensändernden Fehlerberichte wurden rückwirkend auf zuvor veröffentlichte C++-Standards angewendet.

DR angewendet auf Verhalten wie veröffentlicht Korrigiertes Verhalten
LWG 2093 C++11 try_lock_until warf nichts wirft Timeout-bezogene Ausnahmen

[bearbeiten] Siehe auch

sperrt den Mutex, blockiert, wenn der Mutex nicht verfügbar ist
(public member function) [edit]
versucht, den Mutex zu sperren, kehrt zurück, wenn der Mutex nicht verfügbar ist
(public member function) [edit]
versucht, den Mutex zu sperren, kehrt zurück, wenn der Mutex
für die angegebene Zeitdauer nicht verfügbar war
(public member function) [edit]
entsperrt den Mutex
(public member function) [edit]
C-Dokumentation für mtx_timedlock