HikoGUI
A low latency retained GUI
Loading...
Searching...
No Matches
hi::v1::unfair_mutex_impl< UseDeadLockDetector > Class Template Reference

#include <hikogui/concurrency/unfair_mutex_intf.hpp>

Public Member Functions

 unfair_mutex_impl (unfair_mutex_impl const &)=delete
 unfair_mutex_impl (unfair_mutex_impl &&)=delete
unfair_mutex_impl & operator= (unfair_mutex_impl const &)=delete
unfair_mutex_impl & operator= (unfair_mutex_impl &&)=delete
bool is_locked () const noexcept
void lock () noexcept
bool try_lock () noexcept
 When try_lock() is called from a thread that already owns the lock it will return false.
void unlock () noexcept

Detailed Description

template<bool UseDeadLockDetector>
class hi::v1::unfair_mutex_impl< UseDeadLockDetector >

An unfair mutex This is a fast implementation of a 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 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:

  • non-contented:
    • lock(): MOV r,1; XOR r,r; LOCK CMPXCHG; JNE (skip)
    • unlock(): LOCK XADD [],-1; CMP; JE
Template Parameters
UseDeadLockDetectortrue when the unfair_mutex will use the deadlock detector.

Member Function Documentation

◆ try_lock()

template<bool UseDeadLockDetector>
bool hi::v1::unfair_mutex_impl< UseDeadLockDetector >::try_lock ( )
inlinenodiscardnoexcept

When try_lock() is called from a thread that already owns the lock it will return false.

Calling try_lock() in a loop will bypass the operating system's wait system, meaning that no priority inversion will take place.


The documentation for this class was generated from the following files: