rpa::posix_condition Class Reference

#include <posix.h>

List of all members.

Public Types
typedef posix_mutex	mutex_type
Public Member Functions
	posix_condition (posix_mutex *mtxPtr)
	~posix_condition ()
void	wait (void)
void	notify (size_t nbThrs)
Private Attributes
posix_mutex *	_mtx
pthread_cond_t	_cond

---

Detailed Description

All methods (except the constructor) must be called when the mutex is locked. Therefore, the user keeps its total control.

---

Member Typedef Documentation

typedef posix_mutex rpa::posix_condition::mutex_type

---

Constructor & Destructor Documentation

rpa::posix_condition::posix_condition

(

posix_mutex *

mtxPtr

)

rpa::posix_condition::~posix_condition

(

)

---

Member Function Documentation

void rpa::posix_condition::notify

(

size_t

nbThrs

)

This must be called when the mutex is locked. 'pthread_cond_signal()' can be called by a thread whether or not it currently owns the condition variable's associated mutex. For predictible scheduling behaviour and to prevent lost wake-ups, the mutex should be held when signaling a condition variable. The word 'notify' is compatible with Boost's conditions. However, we add the minimum number of threads to notify, and this adds the optimization to make a broadcast if many threads must be notified.

We are sure that a number of threads 'cannot be huge'.

We assume that beyond this number of threads, broadcasting is faster. This is purely implementation-dependent. Maybe there are no threads to notify.

All waiting threads are woken up.

void rpa::posix_condition::wait

(

void

)

This must be called when the mutex is locked. The spurious wake-ups must be detected by the calling program. Therefore, the usual loop is not, and cannot, be implemented here.

---

Member Data Documentation

pthread_cond_t rpa::posix_condition::_cond [private]

posix_mutex* rpa::posix_condition::_mtx [private]

---

The documentation for this class was generated from the following files:

• posix.h
• posix.cpp

---