question about semantics of RT mutexes and RT throttling

question about semantics of RT mutexes and RT throttling

[Chris Friesen]

Hi all,

Just wondering, with PREEMPT_RT on the 6.6 kernel (and I'm curious about 
the 6.12 kernel as well), if a realtime-priority task is on the waiter 
list for a mutex, and RT throttling kicks in, are non-RT tasks able to 
acquire the mutex?   Or does the RT task acquire the mutex even though 
it's supposed to be throttled?  Or does nobody acquire the mutex until 
RT throttling ends?

Just wondering if RT throttling helps at all if multiple RT tasks are 
contending on a mutex at the same time as non-RT tasks?

Thanks,

Chris

Re: question about semantics of RT mutexes and RT throttling

[Sebastian Andrzej Siewior]

On 2025-07-04 14:32:51 [-0600], Chris Friesen wrote:
> Hi all,
> 
> Just wondering, with PREEMPT_RT on the 6.6 kernel (and I'm curious about the
> 6.12 kernel as well), if a realtime-priority task is on the waiter list for
> a mutex, and RT throttling kicks in, are non-RT tasks able to acquire the
> mutex?   Or does the RT task acquire the mutex even though it's supposed to
> be throttled?  Or does nobody acquire the mutex until RT throttling ends?

The rtmutex is priority aware. If a RT-task blocks on a rtmutex then it
is "next" in line before all the SCHED_OTHER tasks. The owner of the
lock has to be a RT task as well either due to its original priority or
due to PI.
Assuming the rtmutex was unlocked before another RT task could lock it
and RT throttling kicked in then any SCHED_OTHER task will not acquire
the lock but go to end of the line and wait for its turn.

> Just wondering if RT throttling helps at all if multiple RT tasks are
> contending on a mutex at the same time as non-RT tasks?

SCHED_OTHER tasks  are always the last in line. RT throttling is only
meant to keep the system going if a RT task is going out of control. Is
not meant to be part of a normal setup.

> Thanks,
> 
> Chris

Sebastian