package core_unix
Install
Dune Dependency
Authors
Maintainers
Sources
md5=9370dca36f518fcea046d2752e3de22b
sha512=c4e8ce9d5885ac8fa8d554a97e1857f3a1c933e0eb5dfd4fe874412b9d09e6d0a2973b644733855553f33f5c859719228f0e6aaf3a2b7eb5befb46fc513750de
doc/core_unix.nano_mutex/Nano_mutex/index.html
Module Nano_mutex
Source
A nano-mutex is a lightweight mutex that can be used only within a single OCaml runtime.
Performance
Nano-mutexes are intended to be significantly cheaper than OS-level mutexes. Creating a nano-mutex allocates a single OCaml record. Locking and unlocking an uncontested nano-mutex each take a handful of instructions. Only if a nano-mutex is contested will it fall back to using an OS-level mutex. If a nano-mutex becomes uncontested again, it will switch back to using an OCaml-only lock.
Nano-mutexes can be faster than using OS-level mutexes because OCaml uses a global lock on the runtime, and requires all running OCaml code to hold the lock. The OCaml compiler only allows thread switches at certain points, and we can use that fact to get the atomic test-and-set used in the core of our implementation without needing any primitive locking, essentially because we're protected by the OCaml global lock.
Here are some benchmarks comparing various mutexes available in OCaml (run in 2020-03):
|----------------------------------+----------+---------| | Name | Time/Run | mWd/Run | |----------------------------------+----------+---------| | Caml_threads.Mutex create | 42.1 ns | 3.00w | | Caml_threads.Mutex lock/unlock | 23.6 ns | | | Error_checking_mutex create | 47.2 ns | 3.00w | | Error_checking_mutex lock/unlock | 25.6 ns | | | Nano_mutex create | 4.4 ns | 4.00w | | Nano_mutex lock/unlock | 12.3 ns | | |----------------------------------+----------+---------|
The benchmark code is in core/extended/lib_test/bench_nano_mutex.ml.
Error handling
For any mutex, there are design choices as to how to behave in certain situations:
- recursive locking (when a thread locks a mutex it already has)
- unlocking an unlocked mutex
- unlocking a mutex held by another thread
Here is a table comparing how the various mutexes behave:
|--------------------+--------------------+----------------------+------------| | | Caml_threads.Mutex | Error_checking_mutex | Nano_mutex | |--------------------+--------------------+----------------------+------------| | recursive lock | undefined | error | error | | unlocking unlocked | undefined | error | error | | t1:lock t2:unlock | undefined | error | error | |--------------------+--------------------+----------------------+------------|
current_thread_has_lock t
returns true
iff the current thread has t
locked.
lock t
locks the mutex t
, blocking until it can be locked. lock
immediately returns Error
if the current thread already holds t
.
try_lock t
locks t
if it can immediately do so. The result indicates whether try_lock
succeeded in acquiring the lock. try_lock
returns Error
if the current thread already holds t
.
unlock t
unlocks t
, if the current thread holds it. unlock
returns Error
if the lock is not held by the calling thread.