ACE
6.1.0
|
Wrapper for readers/writer locks. More...
#include <RW_Mutex.h>
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. | |
bool | removed_ |
Private Member Functions | |
void | operator= (const ACE_RW_Mutex &) |
ACE_RW_Mutex (const ACE_RW_Mutex &) |
Wrapper for readers/writer locks.
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] |
int ACE_RW_Mutex::acquire | ( | void | ) | [inline] |
Note, for interface uniformity with other synchronization wrappers we include the <acquire> method. This is implemented as a write-lock to safe...
int ACE_RW_Mutex::acquire_read | ( | void | ) | [inline] |
Acquire a read lock, but block if a writer hold the lock.
int ACE_RW_Mutex::acquire_write | ( | void | ) | [inline] |
Acquire a write lock, but block if any readers or a writer hold the lock.
void ACE_RW_Mutex::dump | ( | void | ) | const |
Dump the state of an object.
Reimplemented in ACE_RW_Thread_Mutex.
const ACE_rwlock_t & ACE_RW_Mutex::lock | ( | void | ) | const [inline] |
Return the underlying lock.
void ACE_RW_Mutex::operator= | ( | const ACE_RW_Mutex & | ) | [private] |
int ACE_RW_Mutex::release | ( | void | ) | [inline] |
Unlock a readers/writer lock.
int ACE_RW_Mutex::remove | ( | void | ) | [inline] |
Explicitly destroy a readers/writer lock. Note that only one thread should call this method since it doesn't protect against race conditions.
int ACE_RW_Mutex::tryacquire | ( | void | ) | [inline] |
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
.
int ACE_RW_Mutex::tryacquire_read | ( | void | ) | [inline] |
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
.
int ACE_RW_Mutex::tryacquire_write | ( | void | ) | [inline] |
Conditionally acquire a write lock (i.e., won't block).
int ACE_RW_Mutex::tryacquire_write_upgrade | ( | void | ) | [inline] |
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.
Declare the dynamic allocation hooks.
Reimplemented in ACE_RW_Thread_Mutex.
ACE_rwlock_t ACE_RW_Mutex::lock_ [protected] |
Readers/writer lock.
bool 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...