Documented robustness for _umtx_op(2), and updated libthr(3) for knobs added by robust mutexes commit,
Details
- Reviewers
emaste - Group Reviewers
manpages - Commits
- rS300221: Document _umtx_op(2) interface for the implementation of robust mutexes.
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
As usual lots of minor comments on articles, and a few confusing parts
lib/libc/sys/_umtx_op.2 | ||
---|---|---|
108 ↗ | (On Diff #16524) | a non-recoverable state |
126 ↗ | (On Diff #16524) | I think robust is a name that's not particularly descriptive, and wonder if we should say something like |
128 ↗ | (On Diff #16524) | in a transient |
441 ↗ | (On Diff #16524) | On thread termination, the kernel walks two lists of mutexes. |
442 ↗ | (On Diff #16524) | Probably |
445 ↗ | (On Diff #16524) | singly-linked. The link to the next |
450 ↗ | (On Diff #16524) | the kernel What about: Robust list processing is aborted if the kernel finds a mutex with any of the following conditions:
|
453 ↗ | (On Diff #16524) | without the |
473 ↗ | (On Diff #16524) | For each iteration, the mutex is Although perhaps there's no need to refer to iterating here at all, and just describe it as: Every mutex in both lists is unlocked as if... |
484 ↗ | (On Diff #16524) | Perhaps: is locked using the UMTX_OP_MUTEX_LOCK operation? |
488 ↗ | (On Diff #16524) | Also, the kernel handles the UMUTEX_RB_NOTRECOV value of the m_owner field specially, always returning the ENOTRECOVERABLE error for lock attempts, without granting the lock. |
1163 ↗ | (On Diff #16524) | The plurals seem awkward to me here. Does "register the list heads for the current thread's robust mutex lists" seem OK? Or, Register the robust lists's heads for the curren thread |
1186–1187 ↗ | (On Diff #16524) | shared robust locked mutexes seems confusing |
1197 ↗ | (On Diff #16524) | a pointer to |
1202 ↗ | (On Diff #16524) | The kernel inspects |
1205–1209 ↗ | (On Diff #16524) | seems like something is missing here. Right now, it reads as "if the mutex ... is handled more loose," ... then what? |
1289 ↗ | (On Diff #16524) | Maybe umutex where the m_owner field |
1302 ↗ | (On Diff #16524) | The lock was |
1353 ↗ | (On Diff #16524) | unlocking a robust |
1357 ↗ | (On Diff #16524) | allows another thread |
1363 ↗ | (On Diff #16524) | A possible... strengthen the checks |
lib/libthr/libthr.3 | ||
208 ↗ | (On Diff #16524) | by a mapped file |
211 ↗ | (On Diff #16524) | makes such a shared lock object persist ... |
212 ↗ | (On Diff #16524) | by the Virtual |
213 ↗ | (On Diff #16524) | mapped, the kernel |
217 ↗ | (On Diff #16524) | The kernel will... |
222 ↗ | (On Diff #16524) | A non-zero value makes... |
223 ↗ | (On Diff #16524) | prematurely aborted after detecting some inconsistency, as a... |
231 ↗ | (On Diff #16524) | locks a given |