diff options
| author | keramida <keramida@FreeBSD.org> | 2005-01-05 22:04:12 +0000 |
|---|---|---|
| committer | keramida <keramida@FreeBSD.org> | 2005-01-05 22:04:12 +0000 |
| commit | a58020451649cb5efc6052a50c0a9a9d810d3802 (patch) | |
| tree | a92042e30f7d4ff4068f62f002d5271b85b85bed | |
| parent | 77267e277f1c42411d9b7afcf8f397006487b44e (diff) | |
| download | FreeBSD-src-a58020451649cb5efc6052a50c0a9a9d810d3802.zip FreeBSD-src-a58020451649cb5efc6052a50c0a9a9d810d3802.tar.gz | |
Make an attempt at explaining why sx(9) locks cannot be safely obtained
after acquiring a mutex(9).
PR: docs/75571
Submitted by: darrenr
Explanation by: jhb
| -rw-r--r-- | share/man/man9/sx.9 | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/share/man/man9/sx.9 b/share/man/man9/sx.9 index 17ab206..9e5f0eb 100644 --- a/share/man/man9/sx.9 +++ b/share/man/man9/sx.9 @@ -196,6 +196,15 @@ attempting to do so will result in deadlock. A thread may hold a shared or exclusive lock on an .Nm lock while sleeping. +As a result, an +.Nm +lock may not be acquired while holding a mutex. +Otherwise, if one thread slept while holding an +.Nm +lock while another thread blocked on the same +.Nm +lock after acquiring a mutex, then the second thread would effectively +end up sleeping while holding a mutex, which is not allowed. .Sh SEE ALSO .Xr condvar 9 , .Xr mtx_pool 9 , |
