Boost C++ Libraries

...one of the most highly regarded and expertly designed C++ library projects in the world. Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

This is an old version of boost. Click here for the latest version's documentation home page.

C++ Boost

Boost.Threads

Header <boost/thread/condition.hpp>


Contents

Introduction
Classes
Class condition
Class condition synopsis
Class condition constructors and destructor
Class condition modifier functions
Example(s)

Introduction

Include the header <boost/thread/condition.hpp> to define the class condition.

Classes

Class condition

An object of class condition is a synchronization primitive used to cause a thread to wait until a particular shared-data condition (or time) is met. A condition object is always used in conjunction with a mutex object (an object whose type is a model of Mutex or one of its refinements). The mutex object must be locked prior to waiting on the condition, which is verified by passing a lock object (an object whose type is a model of Lock or one of its refinements) to the condition object's wait functions. Upon blocking on the condition object, the thread unlocks the mutex object. When the thread returns from a call to one of the condition object's wait functions the mutex object is again locked. The tricky unlock/lock sequence is performed automatically by the condition object's wait functions.

The condition type is often used to implement the Monitor Object and other important patterns (see [Schmidt 00] and [Hoare 74]). Monitors are one of the most important patterns for creating reliable multithreaded programs.

See Formal Definitions for definitions of thread states blocked and ready. Note that "waiting" is a synonym for blocked.

Class condition synopsis

namespace boost
{
    class condition : private boost::noncopyable // Exposition only.
       // Class condition meets the NonCopyable requirement.
    {
    public:
        condition();
        ~condition();

        void notify_one();
        void notify_all();
        template <typename Lock>
            void wait(Lock& lock);
        template <typename Lock, typename Predicate>
            void wait(Lock& lock, Predicate pred);
        template <typename Lock>
            bool timed_wait(Lock& lock, const xtime& xt);
        template <typename Lock, typename Predicate>
            bool timed_wait(Lock& lock, const xtime& XT, Predicate pred);
    };
};

Class condition constructors and destructor

condition();
Effects: Constructs a condition object.
~condition();
Effects: Destroys *this.

Class condition modifier functions

void notify_one();
Effects: If there is a thread waiting on *this, change that thread's state to ready. Otherwise there is no effect.
Note: If more than one thread is waiting on the condition, it is unspecified which is made ready. After returning to a ready state the notified thread must still acquire the mutex again (which occurs within the call to one of the condition object's wait functions).
void notify_all();
Effects: Change the state of all threads waiting on *this to ready. If there are no waiting threads, notify_all() has no effect.
template <typename ScopedLock>
    void wait(ScopedLock& lock);
Requires: ScopedLock meets the ScopedLock requirements.
Effects: Releases the lock on the mutex model associated with lock, blocks the current thread of execution until readied by a call to this->notify_one() or this->notify_all(), and then reacquires the lock.
Throws: lock_error if !lock.locked()
Danger: This version should always be used within a loop checking that the state logically associated with the condition has become true. Without the loop, race conditions can ensue due to possible "spurious wake ups". The second version encapsulates this loop idiom internally and is generally the preferred method.
Template<typename ScopedLock, typename Pr>
    void wait(ScopedLock& lock, Pr pred);
Requires: ScopedLock meets the ScopedLock requirements, return from pred() convertible to bool.
Effects: As if: while (!pred()) wait(lock)
Throws: lock_error if !lock.locked()
template <typename ScopedLock>
    bool timed_wait(ScopedLock& lock, const xtime& XT);
Requires: ScopedLock meets the ScopedLock requirements.
Effects: Releases the lock on the mutex model associated with the lock, blocks the current thread of execution until readied by a call to this->notify_one() or this->notify_all(), or until XT, and then reacquires the lock.
Returns: false if XT is reached, otherwise true.
Throws: lock_error if !lock.locked()
Danger: This version should always be used within a loop checking that the state logically associated with the condition has become true. Without the loop, race conditions can ensue due to "spurious wake ups". The second version encapsulates this loop idiom internally and is generally the preferred method.
Template<typename ScopedLock, typename Pr>
    bool timed_wait(ScopedLock& lock, const xtime& XT, Pr pred);
Requires: ScopedLock meets the ScopedLock requirements, return from pred() convertible to bool.
Effects: As if:
while (!pred())
{
    if (!timed_wait(lock, XT))
        return false;
}
return true;
Returns: false if XT is reached, otherwise true.
Throws: lock_error if !lock.locked()

Example(s)

libs/thread/example/condition.cpp

Typical output (dependent on scheduling policies) is:

sent: 0
sent: 1
received: 0
received: 1
sent: 2
sent: 3
received: 2
received: 3
sent: 4
received: 4

Revised 09 January, 2003

© Copyright William E. Kempf 2001-2002. All Rights Reserved.

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. William E. Kempf makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.