#include <RW_Mutex.h>
Inheritance diagram for ACE_RW_Mutex:

Public Member Functions | |
| ACE_RW_Mutex (int type=USYNC_THREAD, const ACE_TCHAR *name=0, void *arg=0) | |
| Initialize a readers/writer lock. | |
| ~ACE_RW_Mutex (void) | |
| Implicitly destroy a readers/writer lock. | |
| int | remove (void) |
| int | acquire_read (void) |
| Acquire a read lock, but block if a writer hold the lock. | |
| int | acquire_write (void) |
| int | tryacquire_read (void) |
| int | tryacquire_write (void) |
| Conditionally acquire a write lock (i.e., won't block). | |
| int | tryacquire_write_upgrade (void) |
| int | acquire (void) |
| int | tryacquire (void) |
| int | release (void) |
| Unlock a readers/writer lock. | |
| const ACE_rwlock_t & | lock (void) const |
| Return the underlying lock. | |
| void | dump (void) const |
| Dump the state of an object. | |
Public Attributes | |
| ACE_ALLOC_HOOK_DECLARE | |
| Declare the dynamic allocation hooks. | |
Protected Attributes | |
| ACE_rwlock_t | lock_ |
| Readers/writer lock. | |
| int | removed_ |
Private Member Functions | |
| void | operator= (const ACE_RW_Mutex &) |
| ACE_RW_Mutex (const ACE_RW_Mutex &) | |
These are most useful for applications that have many more parallel readers than writers...
| ACE_RW_Mutex::ACE_RW_Mutex | ( | int | type = USYNC_THREAD, |
|
| const ACE_TCHAR * | name = 0, |
|||
| void * | arg = 0 | |||
| ) |
Initialize a readers/writer lock.
| ACE_RW_Mutex::~ACE_RW_Mutex | ( | void | ) |
Implicitly destroy a readers/writer lock.
| ACE_RW_Mutex::ACE_RW_Mutex | ( | const ACE_RW_Mutex & | ) | [private] |
| ACE_INLINE int ACE_RW_Mutex::acquire | ( | void | ) |
Note, for interface uniformity with other synchronization wrappers we include the <acquire> method. This is implemented as a write-lock to safe...
| ACE_INLINE int ACE_RW_Mutex::acquire_read | ( | void | ) |
Acquire a read lock, but block if a writer hold the lock.
| ACE_INLINE int ACE_RW_Mutex::acquire_write | ( | void | ) |
Acquire a write lock, but block if any readers or a writer hold the lock.
| ACE_BEGIN_VERSIONED_NAMESPACE_DECL void ACE_RW_Mutex::dump | ( | void | ) | const |
| ACE_BEGIN_VERSIONED_NAMESPACE_DECL ACE_INLINE const ACE_rwlock_t & ACE_RW_Mutex::lock | ( | void | ) | const |
Return the underlying lock.
| void ACE_RW_Mutex::operator= | ( | const ACE_RW_Mutex & | ) | [private] |
| ACE_INLINE int ACE_RW_Mutex::release | ( | void | ) |
Unlock a readers/writer lock.
| ACE_INLINE int ACE_RW_Mutex::remove | ( | void | ) |
Explicitly destroy a readers/writer lock. Note that only one thread should call this method since it doesn't protect against race conditions.
| ACE_INLINE int ACE_RW_Mutex::tryacquire | ( | void | ) |
Note, for interface uniformity with other synchronization wrappers we include the <tryacquire> method. This is implemented as a write-lock to be safe... Returns -1 on failure. If we "failed" because someone else already had the lock, <errno> is set to <EBUSY>.
| ACE_INLINE int ACE_RW_Mutex::tryacquire_read | ( | void | ) |
Conditionally acquire a read lock (i.e., won't block). Returns -1 on failure. If we "failed" because someone else already had the lock, <errno> is set to <EBUSY>.
| ACE_INLINE int ACE_RW_Mutex::tryacquire_write | ( | void | ) |
Conditionally acquire a write lock (i.e., won't block).
| ACE_INLINE int ACE_RW_Mutex::tryacquire_write_upgrade | ( | void | ) |
Conditionally upgrade a read lock to a write lock. This only works if there are no other readers present, in which case the method returns 0. Otherwise, the method returns -1 and sets <errno> to <EBUSY>. Note that the caller of this method *must* already possess this lock as a read lock (but this condition is not checked by the current implementation).
Reimplemented in ACE_RW_Thread_Mutex.
ACE_rwlock_t ACE_RW_Mutex::lock_ [protected] |
Readers/writer lock.
int ACE_RW_Mutex::removed_ [protected] |
Keeps track of whether <remove> has been called yet to avoid multiple <remove> calls, e.g., explicitly and implicitly in the destructor. This flag isn't protected by a lock, so make sure that you don't have multiple threads simultaneously calling <remove> on the same object, which is a bad idea anyway...
1.4.6-4