Page MenuHomeFreeBSD

PP mutexes: lock: Check if priority is too high against base one
ClosedPublic

Authored by olce on Feb 23 2024, 5:38 PM.
Tags
None
Referenced Files
F103872047: D44044.id135056.diff
Sat, Nov 30, 1:17 PM
Unknown Object (File)
Sep 20 2024, 8:05 PM
Unknown Object (File)
Sep 20 2024, 2:19 PM
Unknown Object (File)
Sep 19 2024, 7:36 PM
Unknown Object (File)
Sep 19 2024, 5:11 AM
Unknown Object (File)
Sep 16 2024, 4:58 PM
Unknown Object (File)
Sep 14 2024, 12:49 AM
Unknown Object (File)
Sep 11 2024, 8:59 PM
Subscribers

Details

Summary

Doing this instead of using the current (user) priority, which includes
current lendings, prevents gratuitous failures for threads involved in
multiple locking groups, where each group is defined as the threads that
can lock a particular PP or PI mutex. No deadlock can occur in this
case. Indeed, if a thread holds such a lock A giving it a higher
priority than the ceiling of some other lock B that is PP, and B is
acquired by another thread, effectively the latter may not be able to
run but this situation can only last until the first thread releases A,
which it will do eventually.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

olce requested review of this revision.Feb 23 2024, 5:38 PM
This revision is now accepted and ready to land.Feb 26 2024, 4:32 PM