ACE_RW_Mutex Class Reference

Wrapper for readers/writer locks. More...

#include <RW_Mutex.h>

Inheritance diagram for ACE_RW_Mutex:

Inheritance graph
[legend]
List of all members.

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 &)

Detailed Description

Wrapper for readers/writer locks.

These are most useful for applications that have many more parallel readers than writers...


Constructor & Destructor Documentation

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]
 


Member Function Documentation

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.

void ACE_RW_Mutex::dump void   )  const
 

Dump the state of an object.

Reimplemented in ACE_RW_Thread_Mutex.

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.


Member Data Documentation

ACE_RW_Mutex::ACE_ALLOC_HOOK_DECLARE
 

Declare the dynamic allocation hooks.

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...


The documentation for this class was generated from the following files:
Generated on Wed Nov 23 15:50:17 2005 for ACE by  doxygen 1.4.5