Files
cppdraft_translate/cppdraft/thread/mutex/class.md
2025-10-25 03:02:53 +03:00

78 lines
3.0 KiB
Markdown
Raw 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)