BloombergLP::bslmt::ConditionImpl<Platform::PosixThreads>

Synopsis

Declared in <bslmt_conditionimpl_pthread.h>

template<>
class ConditionImpl<Platform::PosixThreads>;

Enums

Name	Description
`Unnamed enum`	The value `timedWait` returns when a timeout occurs.

Member Functions

Name	Description
`ConditionImpl` [constructor]	Create a condition variable object. Optionally specify a `clockType` indicating the type of the system clock against which the `bsls::TimeInterval` `absTime` timeouts passed to the `timedWait` method are to be interpreted (see {Supported Clock-Types} in the component-level documentation). If `clockType` is not specified then the realtime system clock is used. This method does not return normally unless there are sufficient system resources to construct the object.
`~ConditionImpl` [destructor]	Destroy condition variable this object.
`broadcast`	Signal this condition object; wake up all threads that are currently waiting on this condition.
`clockType`	Return the clock type used for timeouts.
`signal`	Signal this condition object; wake up a single thread that is currently waiting on this condition.
`timedWait`	Atomically unlock the specified `mutex` and suspend execution of the current thread until this condition object is "signaled" (i.e., one of the `signal` or `broadcast` methods is invoked on this object) or until the specified `absTime` timeout expires, then re-acquire a lock on the `mutex`. `absTime` is an absolute time represented as an interval from some epoch, which is determined by the clock indicated at construction (see {Supported Clock-Types} in the component-level documentation), and is the earliest time at which the timeout may occur. The `mutex` remains locked by the calling thread upon returning from this function. Return 0 on success, `e_TIMED_OUT` on timeout, and a non-zero value different from `e_TIMED_OUT` if an error occurs. The behavior is undefined unless `mutex` is locked by the calling thread prior to calling this method. Note that spurious wakeups are rare but possible, i.e., this method may succeed (return 0) and return control to the thread without the condition object being signaled. Also note that the actual time of the timeout depends on many factors including system scheduling and system timer resolution, and may be significantly later than the time requested.
`wait`	Atomically unlock the specified `mutex` and suspend execution of the current thread until this condition object is "signaled" (i.e., either `signal` or `broadcast` is invoked on this object in another thread), then re-acquire a lock on the `mutex`. Return 0 on success, and a non-zero value otherwise. Spurious wakeups are rare but possible; i.e., this method may succeed (return 0), and return control to the thread without the condition object being signaled. The behavior is undefined unless `mutex` is locked by the calling thread prior to calling this method. Note that `mutex` remains locked by the calling thread upon return from this function.