HikoGUI
A low latency retained GUI
|
#include <hikogui/concurrency/unfair_recursive_mutex.hpp>
Public Member Functions | |
unfair_recursive_mutex (unfair_recursive_mutex const &)=delete | |
unfair_recursive_mutex & | operator= (unfair_recursive_mutex const &)=delete |
int | recurse_lock_count () const noexcept |
This function should be used in hi_axiom() to check if the lock is held by current thread. | |
bool | try_lock () noexcept |
When try_lock() is called on a thread that already holds the lock true is returned. | |
void | lock () noexcept |
void | unlock () noexcept |
An unfair recursive-mutex This is a fast implementation of a recursive-mutex which does not fairly arbitrate between multiple blocking threads.
Due to the unfairness it is possible that blocking threads will be completely starved.
This recursive-mutex however does block on a operating system's futex/unfair_mutex primitives and therefor thread priority are properly handled.
On windows and Linux the compiler generally emits the following sequence of instructions:
|
inlinenoexcept |
lea rbx,[rcx+98h] mov esi,dword ptr gs:[48h] mov eax,dword ptr [rbx+4] cmp eax,esi jne non_recursive lea r15,[rbx+8] inc dword ptr [r15] jmp locked
non_recursive: call unfair_mutex.lock() lea r15,[r14+0A0h] mov dword ptr [r15],r13d mov dword ptr [rbx+4],esi locked:
|
inlinenoexcept |
This function should be used in hi_axiom() to check if the lock is held by current thread.
0 | The current thread does not have a lock, or no-thread have a lock. |
|
inlinenoexcept |
When try_lock()
is called on a thread that already holds the lock true is returned.