Difference between revisions of "CXMutex"

From cxwiki

Line 1: Line 1:
<div class="mw-parser-output"><div class="mw-parser-output"><div class="mw-parser-output">The CXMutex class is the most basic form of locking primitive. The object exists in one of two states: LOCKED or UNLOCKED. Any thread may lock the object, after which any further attempt (by any thread, including the lock-owner) to lock it again will block until it has been unlocked. The unlock must be performed by the lock-owner thread.</div> <div class="mw-parser-output">&nbsp;</div> <div class="mw-parser-output"><syntaxhighlight lang="C++">void LockMutex(void) const;
+
<div class="mw-parser-output"><div class="mw-parser-output"><div class="mw-parser-output"><div class="mw-parser-output">The CXMutex class is the most basic form of locking primitive. The object exists in one of two states: LOCKED or UNLOCKED. Any thread may lock the object, after which any further attempt (by any thread, including the lock-owner) to lock it again will block until it has been unlocked. The unlock must be performed by the lock-owner thread.</div> <div class="mw-parser-output"><syntaxhighlight lang="language=">// Lock the mutex to the current thread. Blocks while any thread still has the mutex locked.
 +
void LockMutex(void) const;
 +
 
 +
// Unlocks the mutex from the current therad.
 
void UnlockMutex(void) const;
 
void UnlockMutex(void) const;
 +
 +
// Attempts to lock the mutex, but does not block. Returns true if a lock was successfully taken.
 
bool TryAndLockMutex(void) const;
 
bool TryAndLockMutex(void) const;
 
</syntaxhighlight>
 
</syntaxhighlight>
</div>  
+
</div> <div class="mw-parser-output"><syntaxhighlight lang="language=" c++""=""></syntaxhighlight></div>  
 
= Restrictions =
 
= Restrictions =
<div class="mw-parser-output">The CXMutex is UNLOCKED when constructed.</div> <div class="mw-parser-output">The CXMutex should be returned to the UNLOCKED state prior to destruction. It is considered an error for the application to destroy a CXMutex while it is locked, because that would likely to lead to unlock attempts after destruction.</div> <div class="mw-parser-output">An attempt to lock or unlock a CXMutex during or after its destruction is considered an error. The resultant behaviour is undefined. This includes the scenario where a lock attempt is placed prior to destruction, but cannot be honored until destruction has begun.</div> <div class="mw-parser-output">It is considered an error for the application to attempt to lock a CXMutex on the lock-owner thread. The resultant&nbsp;behaviour is undefined, typically leading to either a deadlock, an&nbsp;assertion, or both.</div> <div class="mw-parser-output">No attempt is made to detect or recover from deadlocks. It is the callers responsibility to ensure that locks are taken and released in an approriate manner to avoid deadlocks.</div> <div class="mw-parser-output">&nbsp;</div>
+
 
 +
*The CXMutex is UNLOCKED when constructed.  
 +
*The CXMutex should be returned to the UNLOCKED state prior to destruction. It is considered an error for the application to destroy a CXMutex while it is locked, because that would likely to lead to unlock attempts after destruction.  
 +
*An attempt to lock or unlock a CXMutex during or after its destruction is considered an error. The resultant behaviour is undefined. This includes the scenario where a lock attempt is placed prior to destruction, but cannot be honored until destruction has begun.  
 +
*It is considered an error for the application to attempt to lock a CXMutex on the lock-owner thread. The resultant&nbsp;behaviour is undefined, typically leading to either a deadlock, an&nbsp;assertion, or both.  
 +
*No attempt is made to detect or recover from deadlocks. It is the callers responsibility to ensure that locks are taken and released in an approriate manner to avoid deadlocks.  
 +
*It is considered an error to attempt to unlock a mutex on a thread which is no the lock-owner.
 +
 
 
= Performance =
 
= Performance =
<div class="mw-parser-output">CXMutex uses the underlying OS mutex support, and typically performs a system call. While not horrifically slow, it is measurably slower on average than a CXSpinLock in any case where the lock is low-contention. CXMutex is well-suited to tasks where locking and unlocking do not occur overly frequently, and where the amount of time spent with the lock held is non-trivial.</div> <div class="mw-parser-output">&nbsp;</div> <div class="mw-parser-output">&nbsp;</div> </div> </div>
+
<div class="mw-parser-output">CXMutex uses the underlying OS mutex support, and typically performs a system call. While not horrifically slow, it is measurably slower on average than a CXSpinLock in any case where the lock is low-contention. CXMutex is well-suited to tasks where locking and unlocking do not occur overly frequently, and where the amount of time spent with the lock held is non-trivial.</div> <div class="mw-parser-output">&nbsp;</div> <div class="mw-parser-output">CXMutex inherits&nbsp;the underlying OS guarantees for mutex fairness.</div> <div class="mw-parser-output">&nbsp;</div> <div class="mw-parser-output">&nbsp;</div> </div> </div> </div>

Revision as of 21:23, 22 February 2018

The CXMutex class is the most basic form of locking primitive. The object exists in one of two states: LOCKED or UNLOCKED. Any thread may lock the object, after which any further attempt (by any thread, including the lock-owner) to lock it again will block until it has been unlocked. The unlock must be performed by the lock-owner thread.
// Lock the mutex to the current thread. Blocks while any thread still has the mutex locked.
void LockMutex(void) const;

// Unlocks the mutex from the current therad.
void UnlockMutex(void) const;

// Attempts to lock the mutex, but does not block. Returns true if a lock was successfully taken.
bool TryAndLockMutex(void) const;

Restrictions

  • The CXMutex is UNLOCKED when constructed.
  • The CXMutex should be returned to the UNLOCKED state prior to destruction. It is considered an error for the application to destroy a CXMutex while it is locked, because that would likely to lead to unlock attempts after destruction.
  • An attempt to lock or unlock a CXMutex during or after its destruction is considered an error. The resultant behaviour is undefined. This includes the scenario where a lock attempt is placed prior to destruction, but cannot be honored until destruction has begun.
  • It is considered an error for the application to attempt to lock a CXMutex on the lock-owner thread. The resultant behaviour is undefined, typically leading to either a deadlock, an assertion, or both.
  • No attempt is made to detect or recover from deadlocks. It is the callers responsibility to ensure that locks are taken and released in an approriate manner to avoid deadlocks.
  • It is considered an error to attempt to unlock a mutex on a thread which is no the lock-owner.

Performance

CXMutex uses the underlying OS mutex support, and typically performs a system call. While not horrifically slow, it is measurably slower on average than a CXSpinLock in any case where the lock is low-contention. CXMutex is well-suited to tasks where locking and unlocking do not occur overly frequently, and where the amount of time spent with the lock held is non-trivial.
 
CXMutex inherits the underlying OS guarantees for mutex fairness.