Files
2025-10-25 03:02:53 +03:00

78 lines
3.0 KiB
Markdown
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

[thread.mutex.class]
# 32 Concurrency support library [[thread]](./#thread)
## 32.6 Mutual exclusion [[thread.mutex]](thread.mutex#class)
### 32.6.4 Mutex requirements [[thread.mutex.requirements]](thread.mutex.requirements#thread.mutex.class)
#### 32.6.4.2 Mutex types [[thread.mutex.requirements.mutex]](thread.mutex.requirements.mutex#thread.mutex.class)
#### 32.6.4.2.2 Class mutex [thread.mutex.class]
[🔗](#lib:mutex)
namespace std {class mutex {public:constexpr mutex() noexcept; ~mutex();
mutex(const mutex&) = delete;
mutex& operator=(const mutex&) = delete; void lock(); bool try_lock(); void unlock(); using native_handle_type = *implementation-defined*; // see [[thread.req.native]](thread.req.native "32.2.3Native handles") native_handle_type native_handle(); // see [[thread.req.native]](thread.req.native "32.2.3Native handles")};}
[1](#1)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L7508)
The class mutex provides a non-recursive mutex with exclusive ownership
semantics[.](#1.sentence-1)
If one thread owns a mutex object, attempts by another thread to acquire
ownership of that object will fail (for try_lock()) or block (forlock()) until the owning thread has released ownership with a call tounlock()[.](#1.sentence-2)
[2](#2)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L7516)
[*Note [1](#note-1)*:
After a thread A has called unlock(), releasing a mutex, it is possible for another
thread B to lock the same mutex, observe that it is no longer in use, unlock it, and
destroy it, before thread A appears to have returned from its unlock call[.](#2.sentence-1)
Conforming implementations
handle such scenarios correctly, as long as thread A does not access the
mutex after the unlock call returns[.](#2.sentence-2)
These cases typically occur when a reference-counted object
contains a mutex that is used to protect the reference count[.](#2.sentence-3)
— *end note*]
[3](#3)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L7526)
The class mutex meets
all of the mutex requirements ([[thread.mutex.requirements]](thread.mutex.requirements "32.6.4Mutex requirements"))[.](#3.sentence-1)
It is a standard-layout class ([[class.prop]](class.prop "11.2Properties of classes"))[.](#3.sentence-2)
[4](#4)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L7531)
[*Note [2](#note-2)*:
A program can deadlock if the thread that owns a mutex object callslock() on that object[.](#4.sentence-1)
If the implementation can detect the deadlock,
a resource_deadlock_would_occur error condition might be observed[.](#4.sentence-2)
— *end note*]
[5](#5)
[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L7538)
The behavior of a program is undefined if
it destroys a mutex object owned by any thread or
a thread terminates while owning a mutex object[.](#5.sentence-1)