HikoGUI
A low latency retained GUI
Loading...
Searching...
No Matches
Public Member Functions
v1::unfair_rwmutex Class Reference

#include <hikogui/unfair_rwmutex.hpp>

Public Member Functions

bool is_locked () const noexcept
 
hi_force_inline bool exclusive_try_lock () noexcept
 When try_lock() is called from a thread that already owns the lock it will return false.
 
hi_force_inline void exclusive_lock () noexcept
 
hi_force_inline void exclusive_unlock () noexcept
 Unlock the mutex.
 
hi_force_inline void shared_lock () noexcept
 Get a shared lock.
 
hi_force_inline bool shared_try_lock () noexcept
 
hi_force_inline void shared_unlock () noexcept
 

Detailed Description

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:

Member Function Documentation

◆ exclusive_try_lock()

hi_force_inline bool v1::unfair_rwmutex::exclusive_try_lock ( )
inlinenoexcept

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.

◆ exclusive_unlock()

hi_force_inline void v1::unfair_rwmutex::exclusive_unlock ( )
inlinenoexcept

Unlock the mutex.

Note
It is undefined behavior to call unlock when the thread does not hold the lock.

◆ shared_lock()

hi_force_inline void v1::unfair_rwmutex::shared_lock ( )
inlinenoexcept

Get a shared lock.


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