rt-mutex.txt 3.5 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879
  1. RT-mutex subsystem with PI support
  2. ----------------------------------
  3. RT-mutexes with priority inheritance are used to support PI-futexes,
  4. which enable pthread_mutex_t priority inheritance attributes
  5. (PTHREAD_PRIO_INHERIT). [See Documentation/pi-futex.txt for more details
  6. about PI-futexes.]
  7. This technology was developed in the -rt tree and streamlined for
  8. pthread_mutex support.
  9. Basic principles:
  10. -----------------
  11. RT-mutexes extend the semantics of simple mutexes by the priority
  12. inheritance protocol.
  13. A low priority owner of a rt-mutex inherits the priority of a higher
  14. priority waiter until the rt-mutex is released. If the temporarily
  15. boosted owner blocks on a rt-mutex itself it propagates the priority
  16. boosting to the owner of the other rt_mutex it gets blocked on. The
  17. priority boosting is immediately removed once the rt_mutex has been
  18. unlocked.
  19. This approach allows us to shorten the block of high-prio tasks on
  20. mutexes which protect shared resources. Priority inheritance is not a
  21. magic bullet for poorly designed applications, but it allows
  22. well-designed applications to use userspace locks in critical parts of
  23. an high priority thread, without losing determinism.
  24. The enqueueing of the waiters into the rtmutex waiter list is done in
  25. priority order. For same priorities FIFO order is chosen. For each
  26. rtmutex, only the top priority waiter is enqueued into the owner's
  27. priority waiters list. This list too queues in priority order. Whenever
  28. the top priority waiter of a task changes (for example it timed out or
  29. got a signal), the priority of the owner task is readjusted. [The
  30. priority enqueueing is handled by "plists", see include/linux/plist.h
  31. for more details.]
  32. RT-mutexes are optimized for fastpath operations and have no internal
  33. locking overhead when locking an uncontended mutex or unlocking a mutex
  34. without waiters. The optimized fastpath operations require cmpxchg
  35. support. [If that is not available then the rt-mutex internal spinlock
  36. is used]
  37. The state of the rt-mutex is tracked via the owner field of the rt-mutex
  38. structure:
  39. rt_mutex->owner holds the task_struct pointer of the owner. Bit 0 and 1
  40. are used to keep track of the "owner is pending" and "rtmutex has
  41. waiters" state.
  42. owner bit1 bit0
  43. NULL 0 0 mutex is free (fast acquire possible)
  44. NULL 0 1 invalid state
  45. NULL 1 0 Transitional state*
  46. NULL 1 1 invalid state
  47. taskpointer 0 0 mutex is held (fast release possible)
  48. taskpointer 0 1 task is pending owner
  49. taskpointer 1 0 mutex is held and has waiters
  50. taskpointer 1 1 task is pending owner and mutex has waiters
  51. Pending-ownership handling is a performance optimization:
  52. pending-ownership is assigned to the first (highest priority) waiter of
  53. the mutex, when the mutex is released. The thread is woken up and once
  54. it starts executing it can acquire the mutex. Until the mutex is taken
  55. by it (bit 0 is cleared) a competing higher priority thread can "steal"
  56. the mutex which puts the woken up thread back on the waiters list.
  57. The pending-ownership optimization is especially important for the
  58. uninterrupted workflow of high-prio tasks which repeatedly
  59. takes/releases locks that have lower-prio waiters. Without this
  60. optimization the higher-prio thread would ping-pong to the lower-prio
  61. task [because at unlock time we always assign a new owner].
  62. (*) The "mutex has waiters" bit gets set to take the lock. If the lock
  63. doesn't already have an owner, this bit is quickly cleared if there are
  64. no waiters. So this is a transitional state to synchronize with looking
  65. at the owner field of the mutex and the mutex owner releasing the lock.