fd161d7bf2
As far as I can tell, there is no reason to ignore unlocks, ever; if no threads are waiting, then mutex_unlock() will act appropriately. So all we need to do is increment the lock's count here, as we are relinquishing our request for locking. On the other hand, if we did not find our structure in the lock, that means we own the lock; so to return with an error from here without changing the count would result in a deadlock, as the lock would then be ours, despite our error code implying otherwise. Additionally, take care of part of the case where we have woken up by mutex_destroy(), by setting thread to NULL and checking for it in that case. There is still a race here, however. May fix #16044, as it appears there is a case where ACPICA calls this with a timeout of 0 (we should make this be a mutex_trylock, anyway.) Change-Id: I98215df218514c70ac1922bc3a6f10e01087e44b Reviewed-on: https://review.haiku-os.org/c/haiku/+/2716 Reviewed-by: waddlesplash <waddlesplash@gmail.com> |
||
|---|---|---|
| .. | ||
| build | ||
| compatibility | ||
| config | ||
| cpp | ||
| glibc | ||
| libs | ||
| os | ||
| posix | ||
| private | ||
| tools | ||