aboutsummaryrefslogtreecommitdiff
path: root/docs/ref/api/thr
diff options
context:
space:
mode:
authorGarrett D'Amore <garrett@damore.org>2024-10-06 21:27:54 -0700
committerGarrett D'Amore <garrett@damore.org>2024-10-06 21:27:54 -0700
commitdf8dae72ddb569296ff6ce3cb6c35544cbc3b4d0 (patch)
tree975b1cea6877040e59a448d78b1fc4c5f0f9887b /docs/ref/api/thr
parent415c04a43804cd0e0a4d3f0d49743aedd0ee4cce (diff)
downloadnng-df8dae72ddb569296ff6ce3cb6c35544cbc3b4d0.tar.gz
nng-df8dae72ddb569296ff6ce3cb6c35544cbc3b4d0.tar.bz2
nng-df8dae72ddb569296ff6ce3cb6c35544cbc3b4d0.zip
Indexing improvements to mdbook docs.
Diffstat (limited to 'docs/ref/api/thr')
-rw-r--r--docs/ref/api/thr/nng_mtx.md10
1 files changed, 5 insertions, 5 deletions
diff --git a/docs/ref/api/thr/nng_mtx.md b/docs/ref/api/thr/nng_mtx.md
index ecd00e22..9673ad99 100644
--- a/docs/ref/api/thr/nng_mtx.md
+++ b/docs/ref/api/thr/nng_mtx.md
@@ -19,21 +19,21 @@ void nng_mtx_unlock(nng_mtx *mtx);
## DESCRIPTION
-The {{i:`nng_mutex`}}{{hi:mutex}} structure provides a {{i:mutual-exclusion}} {{i:lock}}, such
+The {{i:`nng_mtx`}}{{hi:mutex}} structure provides a {{i:mutual-exclusion}} {{i:lock}}, such
that only one thread at a time can have the lock (taken using `nng_mtx_lock`).
This is critical for solving certain problems that arise in concurrent programming.
### Initialization and Teardown
-The `nng_mtx` structure is created dynamically, by the application using `nng_mtx_alloc`.
+The `nng_mtx` structure is created dynamically, by the application using {{i:`nng_mtx_alloc`}}.
This function will store a pointer to the allocate mutex at the location signified by _mtxp_.
When the application has no further need of the mutex, it can deallocate the resources
-associated using the `nng_mtx_free` function.
+associated using the {{i:`nng_mtx_free`}} function.
### Locking and Unlocking
-The `nng_mtx` lock can be acquired by a calling thread using the `nng_mtx_lock` function.
+The `nng_mtx` lock can be acquired by a calling thread using the {{i:`nng_mtx_lock`}} function.
The caller will block until the lock is acquired.
If multiple threads are contending for ownership of the lock, the order of
@@ -45,7 +45,7 @@ acquisition is not specified, and applications must not depend on it.
> It is a programming error for the owner of a mutex to attempt to
> reacquire it.
-The lock can be released by the thread that has ownership using the `nng_mtx_unlock` function.
+The lock can be released by the thread that has ownership using the {{i:`nng_mtx_unlock`}} function.
> [!NOTE]
> A mutex can _only_ be unlocked by the thread that locked it.