| Home | Libraries | People | FAQ | More

## Class try_mutex

boost::try_mutex —

The try_mutex class is a model of the TryMutex concept.

## Synopsis

    class try_mutex : private boost::noncopyable   // Exposition only
    {
    public:
      // types
      typedef implementation-defined scoped_lock;
      typedef implementation-defined scoped_try_lock;

      // construct/copy/destruct
      try_mutex();
      ~try_mutex();
    };

## Description

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.

### `try_mutex` construct/copy/destruct

1.     try_mutex();

   Effects: Constructs a try_mutex object.
   Postconditions: `*this` is in an unlocked state.

2.     ~try_mutex();

   Effects: Destroys a try_mutex object.
   Requires: `*this` is in an unlocked state.
   Notes: Danger: Destruction of a locked mutex is a serious programming error resulting in undefined behavior such as a program crash.

| Copyright © 2001-2003 William E. Kempf