![]()  | 
Home | Libraries | People | FAQ | More | 
The 1.41.0 release of Boost adds futures to the thread library. There are also a few minor changes.
The 1.36.0 release of Boost includes a few new features in the thread library:
lock()
          and try_lock()
          functions for locking multiple mutexes at once.
        scoped_try_lock types are
          now backwards-compatible with Boost 1.34.0 and previous releases.
        boost::thread constructor.
        timed_lock
          and timed_wait functions
          to allow use of xtime for
          timeouts.
        Almost every line of code in Boost.Thread has been changed since the 1.34 release of boost. However, most of the interface changes have been extensions, so the new code is largely backwards-compatible with the old code. The new features and breaking changes are described below.
boost::thread and of the various lock
          types are now movable.
        Lockable concept, through the
          use of boost::condition_variable_any (boost::condition is a typedef
          to boost::condition_variable_any, provided for
          backwards compatibility). boost::condition_variable
          is provided as an optimization, and will only work with boost::unique_lock<boost::mutex> (boost::mutex::scoped_lock).
        boost::thread, so a thread can obtain
          it's own ID (using boost::this_thread::get_id()), and IDs can be used as keys in associative
          containers, as they have the full set of comparison operators.
        boost::system_time for absolute timeouts, and
          with support for relative timeouts in many cases. boost::xtime
          is supported for backwards compatibility only.
        boost::lock_guard,
          boost::unique_lock, boost::shared_lock,
          and boost::upgrade_lock, which are templated on
          the type of the mutex. The Lockable concept has been extended
          to include publicly available lock()
          and unlock()
          member functions, which are used by the lock types.
        The list below should cover all changes to the public interface which break backwards compatibility.
boost::try_mutex has been removed, and
          the functionality subsumed into boost::mutex. boost::try_mutex is left as a typedef, but is no longer a separate class.
        boost::recursive_try_mutex has been removed,
          and the functionality subsumed into boost::recursive_mutex. boost::recursive_try_mutex is left as
          a typedef, but is no longer
          a separate class.
        boost::detail::thread::lock_ops has been removed. Code that
          relies on the lock_ops
          implementation detail will no longer work, as this has been removed, as
          it is no longer necessary now that mutex types now have public lock()
          and unlock()
          member functions.
        scoped_lock constructors
          with a second parameter of type bool
          are no longer provided. With previous boost releases, 
boost::mutex::scoped_lock some_lock(some_mutex,false);could be used to create a lock object that was associated with a mutex, but did not lock it on construction. This facility has now been replaced with the constructor that takes a
boost::defer_lock_type
          as the second parameter: 
boost::mutex::scoped_lock some_lock(some_mutex,boost::defer_lock);
locked()
          member function of the scoped_lock
          types has been renamed to owns_lock().
        boost::thread instance representing the
          current thread: a default-constructed boost::thread object is not associated
          with any thread. The only use for such a thread object was to support the
          comparison operators: this functionality has been moved to boost::thread::id.
        boost::read_write_mutex has been replaced with
          boost::shared_mutex.
        boost::mutex is now never recursive.
          For Boost releases prior to 1.35 boost::mutex was recursive on Windows
          and not on POSIX platforms.
        boost::recursive_mutex with a call to
          boost::condition_variable_any::wait(),
          the mutex is only unlocked one level, and not completely. This prior behaviour
          was not guaranteed and did not feature in the tests.