CARVIEW |
Select Language
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 28 Jul 2025 02:38:07 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Location: /reference/mutex/mutex/lock/
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 28 Jul 2025 02:38:08 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
ETag: W/"7e05-Kb+4l8h3uCBeAafTkK3xmjKZftU"
Content-Encoding: gzip
The calling thread locks the mutex, blocking if necessary:
All lock and unlock operations on the mutex follow a single total order, with all visible effects synchronized between the lock operations and previous unlock operations on the same object.
The non-member function lock allows to lock more than one mutex object simultaneously, avoiding the potential deadlocks that can happen when multiple threads lock/unlock individual mutex objects in different orders.
Note that the order in which different concurrent locks are scheduled to return is unspecified, and not necessarily related to the order in which they are locked (depending on the system and library implementation).
Possible output (order of lines may vary, but they are never intermingled):
If the mutex is already locked by the current thread, calling this function causes a deadlock (undefined behavior): on certain library implementations, this causes the function to fail.
If the call fails, a system_error exception is thrown:
Depending on the library implementation, this member function may also throw exceptions to report other situations.
Reference
C library:
- <cassert> (assert.h)
- <cctype> (ctype.h)
- <cerrno> (errno.h)
-
<cfenv> (fenv.h)C++11
- <cfloat> (float.h)
-
<cinttypes> (inttypes.h)C++11
- <ciso646> (iso646.h)
- <climits> (limits.h)
- <clocale> (locale.h)
- <cmath> (math.h)
- <csetjmp> (setjmp.h)
- <csignal> (signal.h)
- <cstdarg> (stdarg.h)
-
<cstdbool> (stdbool.h)C++11
- <cstddef> (stddef.h)
-
<cstdint> (stdint.h)C++11
- <cstdio> (stdio.h)
- <cstdlib> (stdlib.h)
- <cstring> (string.h)
-
<ctgmath> (tgmath.h)C++11
- <ctime> (time.h)
-
<cuchar> (uchar.h)C++11
- <cwchar> (wchar.h)
- <cwctype> (wctype.h)
Containers:
-
<array>C++11
- <deque>
-
<forward_list>C++11
- <list>
- <map>
- <queue>
- <set>
- <stack>
-
<unordered_map>C++11
-
<unordered_set>C++11
- <vector>
-
Input/Output:
Multi-threading:
-
<atomic>C++11
-
<condition_variable>C++11
-
<future>C++11
-
<mutex>C++11
-
<thread>C++11
-
Other:
- <algorithm>
- <bitset>
-
<chrono>C++11
-
<codecvt>C++11
- <complex>
- <exception>
- <functional>
-
<initializer_list>C++11
- <iterator>
- <limits>
- <locale>
- <memory>
- <new>
- <numeric>
-
<random>C++11
-
<ratio>C++11
-
<regex>C++11
- <stdexcept>
- <string>
-
<system_error>C++11
-
<tuple>C++11
-
<type_traits>C++11
-
<typeindex>C++11
- <typeinfo>
- <utility>
- <valarray>
<mutex>
classes
-
adopt_lock_tC++11
-
defer_lock_tC++11
-
lock_guardC++11
-
mutexC++11
-
once_flagC++11
-
recursive_mutexC++11
-
recursive_timed_mutexC++11
-
timed_mutexC++11
-
try_to_lock_tC++11
-
unique_lockC++11
-
functions
constants
-
adopt_lockC++11
-
defer_lockC++11
-
try_to_lockC++11
-
mutex
-
mutex::~mutexC++11
-
mutex::mutexC++11
member functions
-
mutex::lockC++11
-
mutex::native_handleC++11
-
mutex::try_lockC++11
-
mutex::unlockC++11
-
public member function
<mutex>
std::mutex::lock
void lock();
Lock mutex
- If the mutex isn't currently locked by any thread, the calling thread locks it (from this point, and until its member unlock is called, the thread owns the mutex).
- If the mutex is currently locked by another thread, execution of the calling thread is blocked until unlocked by the other thread (other non-locked threads continue their execution).
- If the mutex is currently locked by the same thread calling this function, it produces a deadlock (with undefined behavior). See recursive_mutex for a mutex type that allows multiple locks from the same thread.
All lock and unlock operations on the mutex follow a single total order, with all visible effects synchronized between the lock operations and previous unlock operations on the same object.
The non-member function lock allows to lock more than one mutex object simultaneously, avoiding the potential deadlocks that can happen when multiple threads lock/unlock individual mutex objects in different orders.
Note that the order in which different concurrent locks are scheduled to return is unspecified, and not necessarily related to the order in which they are locked (depending on the system and library implementation).
Parameters
noneReturn value
noneExample
|
|
Possible output (order of lines may vary, but they are never intermingled):
thread #1 thread #2 thread #3 thread #4 thread #5 thread #6 thread #7 thread #8 thread #9 thread #10 |
Data races
The mutex object is modified as an atomic operation (causing no data races).Exception safety
Basic guarantee: if an exception is thrown by this member function, the mutex object is left in a valid state. Further, a lock is never acquired by the thread that made the throwing call.If the mutex is already locked by the current thread, calling this function causes a deadlock (undefined behavior): on certain library implementations, this causes the function to fail.
If the call fails, a system_error exception is thrown:
exception type | error condition | description |
---|---|---|
system_error | errc::resource_deadlock_would_occur | A deadlock was detected (implementations may detect certain cases of deadlock). |
system_error | errc::operation_not_permitted | The thread does not have privileges to perform the operation. |
system_error | errc::device_or_resource_busy | The native handle type manipulated is already locked. |
See also
- mutex::try_lock
- Lock mutex if not locked (public member function)
- mutex::unlock
- Unlock mutex (public member function)
Home page | Privacy policy
© cplusplus.com, 2000-2025 - All rights reserved - v3.3.4s
Spotted an error? contact us
© cplusplus.com, 2000-2025 - All rights reserved - v3.3.4s
Spotted an error? contact us