Rogue Wave banner
Previous fileTop of DocumentContentsIndexNext file

RWCondition


RWCondition RWSynchObject

Data Type and Member Function Indexes
(exclusive of constructors and destructors)

Data Types

Member Functions

Package

Synchronization

Header File

#include <rw/sync/RWCondition.h>

Description

An RWCondition object is a condition variable that can be used to delay a thread until the program state satisfies some boolean condition, and to awaken that thread once the condition becomes true.

The name condition variable is perhaps a misnomer. The name seems to imply that a condition variable encapsulates a condition. This is not the case. A condition variable is associated with some arbitrary condition in a program. It simply provides a mechanism for threads to wait and signal. It is up to the programmer to code the application such that it waits at the appropriate point of execution when the condition is false, and to signal appropriately when the condition becomes true.

A condition variable must be initialized with a mutex. The mutex must be the same as is used to protect the program state involved in the condition test. To delay on a condition variable, a thread calls the wait() member. The wait() function atomically releases the lock and logically adds the thread to a list of threads that are waiting on the same condition. Another thread can unblock one waiting thread, if there are any, by calling the signal() member function. All waiting threads can be awakened at once by calling the signalAll() member function. For each awakened thread, the wait() function reacquires the lock and returns control to the calling routine.

To use an RWCondition object, a boolean expression is evaluated under the protection of a mutex lock. When the expression is false, the thread blocks on the condition variable and the mutex is released. The condition variable is then signaled by another thread following changes to the state being evaluated by the conditional expression. This causes one or all of the threads, depending on whether signal() or signalAll() is used, to block on the condition to awaken and to try to reacquire the lock.

A thread should always retest the condition when it is awakened, as the condition might have changed by the time it can reacquire the condition mutex. This is typically done in a loop:

When using RWCondition in a class inheriting from RWTMonitor<T>, it is not uncommon to initialize the RWCondition with the monitor's mutex.

Example

Global Typedefs

typedef pthread_cond_t RWConditionRep;
typedef cond_t RWConditionRep;

Public Typedefs

typedef RWTLockGuard<RWCondition>       LockGuard;
typedef RWTTryLockGuard<RWCondition>    TryLockGuard;
typedef RWTUnlockGuard<RWCondition>     UnLockGuard;

Public Constructor

RWCondition(RWMutexLock& mutex,
          RWCancellationState state=RW_CANCELLATION_DISABLED);

Destructor

~RWCondition();

Public Member Functions

void
acquire(void);
RWWaitStatus 
acquire(unsigned long milliseconds);
RWConditionRep* 
getConditionRep(void) const;
void 
release(void);
void 
signal(void);
void 
signalAll(void);
RWBoolean 
tryAcquire(void);
void
wait(void);
RWWaitStatus 
wait(unsigned long milliseconds);

Private Copy Constructor

RWCondition(const RWCondition& second);

Private Member Operator

RWCondition&
operator=(const RWCondition& second);


Previous fileTop of DocumentContentsIndexNext file

©Copyright 2000, Rogue Wave Software, Inc.
Contact Rogue Wave about documentation or support issues.