I wrote, on 11 Oct 2022:
>
> 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 rationale also conflicts with itself. Consider what happens in
the following scenario if, as the rationale suggests, the thread at
the head of the queue is not removed until it blocks or exits:
- The system has two or more CPUs.
- A CPU becomes available and the highest priority queue has
two threads: the head which is running and second thread
that is runnable but not running.
The rationale says "When selecting a process to run, the system always
selects the first process from the highest priority queue with a
runnable process." But the first process in the queue is already
running - it would need to say that the system selects the first
process that isn't already running. (Again, it should say thread not
process.)
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
