Details
- Reviewers
emaste markj jilles - Group Reviewers
manpages - Commits
- rGbe6116fdfc4d: pthread_mutexattr(3): document each pthread_mutexattr_set/get* function
rGf5b9747075a9: libthr(3): explain some internals of the locks implementation
rG6bda192013fc: pthread_mutexattr(3): install pthread_mutexattr_get/setpshared links
rG9f3b6cdbe87c: pthread_mutexattr(3): use .Fo/.Fc to avoid too long lines
rG0a6e5fc29b43: pthread_mutexattr(3): document pthread_mutexattr_set/getpshared
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
| lib/libthr/libthr.3 | ||
|---|---|---|
| 266 | Maybe "all synchronization objects (e.g., pthread_mutex_t) ..." | |
| 266 | ||
| 267 | ||
| 269 | ||
| 271 | ||
| 272 | ||
| 273 | ||
| 286 | ||
| 291 | ||
| 308 | Maybe s/this/the FreeBSD/, assuming I understood correctly. | |
| 308 | ||
| 311 | ||
| share/man/man3/pthread_mutexattr.3 | ||
| 111 | ||
| 112 | ||
| 128 | ||
| 133 | Is "priority ceiling" explained anywhere? It is mentioned above with pthread_mutexattr_setprioceiling() but not really explained. | |
| 138 | I think it should be "the robustness attribute" or something like that. Otherwise it seems like "robust" is an adjective for "attribute" and it reads strangely. | |
| 145 | "owning the mutex" and "while holding the mutex lock" are saying the same thing. | |
| 146 | In what scenario can another thread unlock a mutex held by a terminated thread? | |
| 159 | or "unrecoverable" | |
| 167 | ||
| 168 | "The type" or ".Va type" | |
| 174 | I'd add commas after "recursive locking" and "current thread". Otherwise it sounds like "recursive" applies to both locking and unlocking. | |
| 175 | ||
| 178 | ||
| 180 | Same comment about commas. | |
| 185 | or "causes an error to be returned" as you wrote above. | |
| share/man/man3/pthread_mutexattr.3 | ||
|---|---|---|
| 133 | Basically the sentence above is the definition of the ceiling. SUSv8 contains much more elaborate description, I am not sure that we want to copy/paste it there. Might be in the next iteration, some text could be composed. | |
| 146 | This is mostly literal text from SUSv8. For normal and default non-robust types, they state that unlocking locked but not owned mutex is UB. They also talk about an option of not storing id of the owning thread for such mutexes in rationale. It is as if they want to avoid preventing an implementation from disallowing that. And for robust mutexes, unlock from other thread is the way in which the abandoned mutex is handled. This is described by the PTHREAD_MUTEX_ROBUST item below. | |
| 159 | I believe I took the term from SUS. | |
| share/man/man3/pthread_mutexattr.3 | ||
|---|---|---|
| 159 | SUS seems to say "unusable"? In any case, I forgot that "unrepairable" is also an option, there was a typo in the initial version is all. I have no preference, they all seem correct. | |