%threads.entities; ]>

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.