FlagLockGeneric< IsPriorityInherited > Class Template Reference
A simple flag log, wrapping an atomic word used with the futex calls. More...
#include <locks.hh>
Public Member Functions | |
| bool | try_lock (TimeoutArgument timeout) |
| Attempt to acquire the lock, blocking until a timeout specified by the timeout parameter has expired. | |
| bool | try_lock () |
| Try to acquire the lock, do not block. | |
| void | lock () |
| Acquire the lock, potentially blocking forever. | |
| void | unlock () |
| Release the lock. | |
| void | upgrade_for_destruction () |
| Set the lock in destruction mode. | |
| uint16_t | get_owner_thread_id () |
| Return the thread ID of the owner of the lock. | |
Detailed Description
template<bool IsPriorityInherited>
class FlagLockGeneric< IsPriorityInherited >
class FlagLockGeneric< IsPriorityInherited >
A simple flag log, wrapping an atomic word used with the futex calls.
Threads blocked on this will be woken in priority order. If IsPriorityInherited is set, priority is inherited by waiters to avoid priority inversion issues.
The lock word that this wraps is directly accessibly by any malicious compartment that has a reference to this thread. If this is a security concern then you may have other problems: a malicious compartment with access to a mutex's interface (irrespective of the underlying implementation) can cause deadlock by spuriously acquiring a lock or cause data corruption via races by spuriously releasing it. Anything that requires mutual exclusion in the presence of mutual distrust should consider an using a lock manager compartment with an API that returns a single-use capability to unlock on any lock call.
Flag locks are not recursive; if needed, use a RecursiveMutex instead.
Member Function Documentation
◆ get_owner_thread_id()
template<bool IsPriorityInherited>
|
inline |
Return the thread ID of the owner of the lock.
This is only available for priority inherited locks, as this is the only case where we store the thread ID of the owner. See the documentation of flaglock_priority_inheriting_get_owner_thread_id for more information.
◆ lock()
template<bool IsPriorityInherited>
|
inline |
Acquire the lock, potentially blocking forever.
This function returns void despite that this is a bad idea. Because the C++ standard library has void-returning ::lock() methods, templated callers would not check a return value, making it unsafe to return in the event of failed lock acquisition. Failures instead manifest as tripping a Debug::Invariant, causing this function not to return (and yet not block forever). Thus, it is not safe with locks that may be put into "destrucion mode" (see flaglock_upgrade_for_destruction). Attempting to recursively lock a held priority inheriting flag lock (acquired by either lock or try_lock) will trip the same Invariant. (Recall that flag locks explicitly do not support recursive acquisition; the failure mode is, however, not one of blocking forever.) In general, defensive code should prefer try_lock.
◆ try_lock() [1/2]
template<bool IsPriorityInherited>
|
inline |
Try to acquire the lock, do not block.
Returns true if and only if the lock transitioned from being unheld to held by the current thread.
Definition at line 87 of file locks.hh.
Referenced by FlagLockGeneric< false >::try_lock().
◆ try_lock() [2/2]
template<bool IsPriorityInherited>
|
inline |
◆ unlock()
template<bool IsPriorityInherited>
|
inline |
◆ upgrade_for_destruction()
template<bool IsPriorityInherited>
|
inline |
Set the lock in destruction mode.
See the documentation of flaglock_upgrade_for_destruction for more information.
The documentation for this class was generated from the following file:
- sdk/include/locks.hh
Generated by
1.18.0