Re: the last bitI think that's to account for the case where an implementation may asynchronously allow an app thread to modify the base priority while another thread is blocked on it, not that the example sched_setparam() has to be in the same thread. While just adding it to the tail of the new queues list may be fastest to accomplish, I think doing an insertion, at head or a spot where relative time to get to head of queue nearest the same as old queue position is more the desired behavior. On Tue, Oct 11, 2022 at 4:41 AM, Geoff Clare via austin-group-l at The Open Group<austin-group-l@opengroup.org> wrote: I wrote, on 10 Oct 2022: > > I'm trying to understand the second sentence in this paragraph on the > pthread_mutexattr_getprotocol() page: > > While a thread is holding a mutex which has been initialized > with the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol > attributes, it shall not be subject to being moved to the tail > of the scheduling queue at its priority in the event that its > original priority is changed, such as by a call to sched_setparam(). > Likewise, when a thread unlocks a mutex that has been initialized > with the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol > attributes, it shall not be subject to being moved to the tail of > the scheduling queue at its priority in the event that its original > priority is changed. > > The first sentence is no problem. It's pointing out that items 7 and 8a > in the description of SCHED_FIFO don't apply to this change of the > thread's normal priority (since it isn't currently executing at that > priority). > > But when a thread unlocks a PRIO_PROTECT mutex, in the simple case > where locking the mutex caused its priority to be raised and unlocking > it causes its priority to revert to its original value, it has to be > moved from the queue for the higher priority to the queue for its > original priority, so it doesn't make any sense to me that the text > above talks about moving within a queue, and why does it say "in the > event that its original priority is changed"?
After further reading, I'm not sure it is in a queue at all when it unlocks the mutex. The rationale implies that it is: The process at the front of the ready list is executed until it exits or becomes blocked, at which point it is removed from the list. (it says "process" not "thread", but I think that's just because it is out of date compared to the normative text it is commenting on). However, the normative text says the queue is "a thread list that is ordered by the time its threads have been on the list without being executed". The use of "without being executed" here implies that the thread at the head of the list is removed from the list when it starts execution, not left there until it blocks or exits. > The only way I can get any sense out of it is to take it as meaning > that when the thread moves from the queue for the higher priority to > the queue for its original priority, it should be placed at the head > not the tail, which seems reasonable, but it's very unclear. If the thread is not on a queue at all while it is running, then the point of the second sentence in the paragraph I originally quoted is presumably to stop item 7 in the SCHED_FIFO description from requiring that the thread is placed on a queue when it unlocks the mutex. I.e. it keeps running, but now at its original priority (unless unlocking the mutex makes a higher priority thread runnable, in which it would be pre-empted by the higher priority thread). However, the last bit "in the event that its original priority is changed" still makes no sense. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
