The `mutex` class is a model of the Mutex concept.

The `mutex` class is a model of the Mutex concept. It should be used to synchronize access to shared resources using Unspecified locking mechanics.

For classes that model related mutex concepts, see `try_mutex` and `timed_mutex`.

For Recursive locking mechanics, see `recursive_mutex`, `recursive_try_mutex`, and `recursive_timed_mutex`.

The `mutex` class supplies the following typedef, which models the specified locking strategy:

Lock Name | Lock Concept
--- | ---
scoped_lock | ScopedLock

The `mutex` class uses an Unspecified locking strategy, so attempts to recursively lock a `mutex` object or attempts to unlock one by threads that don't own a lock on it result in undefined behavior. This strategy allows implementations to be as efficient as possible on any given platform. It is, however, recommended that implementations include debugging support to detect misuse when `NDEBUG` is not defined.

Like all mutex models in &Boost.Threads;, `mutex` leaves the scheduling policy as Unspecified. Programmers should make no assumptions about the order in which waiting threads acquire a lock.

`boost::noncopyable` Exposition only
implementation-defined
Constructs a `mutex` object.
*this
is in an unlocked state.
Destroys a `mutex` object.
*this
is in an unlocked state.
Danger: Destruction of a locked mutex is a serious programming error resulting in undefined behavior such as a program crash.

The `try_mutex` class is a model of the TryMutex concept.

The `try_mutex` class is a model of the TryMutex concept. It should be used to synchronize access to shared resources using Unspecified locking mechanics.

For classes that model related mutex concepts, see `mutex` and `timed_mutex`.

For Recursive locking mechanics, see `recursive_mutex`, `recursive_try_mutex`, and `recursive_timed_mutex`.

The `try_mutex` class supplies the following typedefs, which model the specified locking strategies:

Lock Name | Lock Concept
--- | ---
scoped_lock | ScopedLock
scoped_try_lock | ScopedTryLock

The `try_mutex` class uses an Unspecified locking strategy, so attempts to recursively lock a `try_mutex` object or attempts to unlock one by threads that don't own a lock on it result in undefined behavior. This strategy allows implementations to be as efficient as possible on any given platform. It is, however, recommended that implementations include debugging support to detect misuse when `NDEBUG` is not defined.

Like all mutex models in &Boost.Threads;, `try_mutex` leaves the scheduling policy as Unspecified. Programmers should make no assumptions about the order in which waiting threads acquire a lock.

`boost::noncopyable` Exposition only
implementation-defined
implementation-defined
Constructs a `try_mutex` object.
*this
is in an unlocked state.
Destroys a `try_mutex` object.
*this
is in an unlocked state.
Danger: Destruction of a locked mutex is a serious programming error resulting in undefined behavior such as a program crash.

The `timed_mutex` class is a model of the TimedMutex concept.

The `timed_mutex` class is a model of the TimedMutex concept. It should be used to synchronize access to shared resources using Unspecified locking mechanics.

For classes that model related mutex concepts, see `mutex` and `try_mutex`.

For Recursive locking mechanics, see `recursive_mutex`, `recursive_try_mutex`, and `recursive_timed_mutex`.

The `timed_mutex` class supplies the following typedefs, which model the specified locking strategies:

Lock Name | Lock Concept
--- | ---
scoped_lock | ScopedLock
scoped_try_lock | ScopedTryLock
scoped_timed_lock | ScopedTimedLock

The `timed_mutex` class uses an Unspecified locking strategy, so attempts to recursively lock a `timed_mutex` object or attempts to unlock one by threads that don't own a lock on it result in undefined behavior. This strategy allows implementations to be as efficient as possible on any given platform. It is, however, recommended that implementations include debugging support to detect misuse when `NDEBUG` is not defined.

Like all mutex models in &Boost.Threads;, `timed_mutex` leaves the scheduling policy as Unspecified. Programmers should make no assumptions about the order in which waiting threads acquire a lock.

`boost::noncopyable` Exposition only
implementation-defined
implementation-defined
implementation-defined
Constructs a `timed_mutex` object.
*this
is in an unlocked state.
Destroys a `timed_mutex` object.
*this
is in an unlocked state.
Danger: Destruction of a locked mutex is a serious programming error resulting in undefined behavior such as a program crash.