Namensräume
Varianten
Aktionen

std::defer_lock, std::try_to_lock, std::adopt_lock, std::defer_lock_t, std::try_to_lock_t, std::adopt_lock_t

Von cppreference.com
< cpp‎ | thread
 
 
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)
defer_locktry_to_lockadopt_lockdefer_lock_ttry_to_lock_tadopt_lock_t
(C++11)(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
 
Definiert in Header <mutex>
struct defer_lock_t { explicit defer_lock_t() = default; };
(1) (seit C++11)
constexpr std::defer_lock_t defer_lock {};
(2) (seit C++11)
(inline seit C++17)
struct try_to_lock_t { explicit try_to_lock_t() = default; };
(3) (seit C++11)
constexpr std::try_to_lock_t try_to_lock {};
(4) (seit C++11)
(inline seit C++17)
struct adopt_lock_t { explicit adopt_lock_t() = default; };
(5) (seit C++11)
constexpr std::adopt_lock_t adopt_lock {};
(6) (seit C++11)
(inline seit C++17)
1,3,5) Die leeren Klassentypen std::defer_lock_t, std::try_to_lock_t und std::adopt_lock_t können in der Parameterliste des Konstruktors für std::unique_lock und std::shared_lock verwendet werden, um die Sperrstrategie zu spezifizieren.
2,4,6) Die entsprechenden Instanzen std::defer_lock, std::try_to_lock und std::adopt_lock von (1,3,5) können an die Konstruktoren übergeben werden, um die Art der Sperrstrategie anzugeben.

Einer der Konstruktoren der Klassenschablone std::lock_guard akzeptiert nur das Tag std::adopt_lock.

Typ Effekt(e)
defer_lock_t übernehmen Sie nicht den Besitz des Mutex
try_to_lock_t versuchen Sie, den Besitz des Mutex zu erlangen, ohne zu blockieren
adopt_lock_t gehen Sie davon aus, dass der aufrufende Thread bereits den Besitz des Mutex hat

[bearbeiten] Beispiel

#include <iostream>
#include <mutex>
#include <thread>
 
struct bank_account
{
    explicit bank_account(int balance) : balance{balance} {}
    int balance;
    std::mutex m;
};
 
void transfer(bank_account& from, bank_account& to, int amount)
{
    if (&from == &to) // avoid deadlock in case of self transfer
        return;
 
    // lock both mutexes without deadlock
    std::lock(from.m, to.m);
    // make sure both already-locked mutexes are unlocked at the end of scope
    std::lock_guard lock1{from.m, std::adopt_lock};
    std::lock_guard lock2{to.m, std::adopt_lock};
 
// equivalent approach:
//  std::unique_lock<std::mutex> lock1{from.m, std::defer_lock};
//  std::unique_lock<std::mutex> lock2{to.m, std::defer_lock};
//  std::lock(lock1, lock2);
 
    from.balance -= amount;
    to.balance += amount;
}
 
int main()
{
    bank_account my_account{100};
    bank_account your_account{50};
 
    std::thread t1{transfer, std::ref(my_account), std::ref(your_account), 10};
    std::thread t2{transfer, std::ref(your_account), std::ref(my_account), 5};
 
    t1.join();
    t2.join();
 
    std::cout << "my_account.balance = " << my_account.balance << "\n"
                 "your_account.balance = " << your_account.balance << '\n';
}

Ausgabe

my_account.balance = 95
your_account.balance = 55

[bearbeiten] Siehe auch

konstruiert einen lock_guard, der optional den gegebenen Mutex sperrt
(public member function of std::lock_guard<Mutex>) [bearbeiten]
konstruiert einen unique_lock, der optional den übergebenen Mutex sperrt (d. h. den Besitz übernimmt)
(public member function of std::unique_lock<Mutex>) [bearbeiten]