Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001610 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Clarification Requested 2022-10-21 08:07 2022-11-08 14:18
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Applied  
Name Geoff Clare
Organization The Open Group
User Reference
Section pthread_mutexattr_getprotocol()
Page Number 1687
Line Number 55047
Interp Status ---
Final Accepted Text
Summary 0001610: Scheduling requirements when unlocking a prioceiling mutex
Description The description of pthread_mutexattr_setprotocol() includes the following:
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.

As discussed on the mailing list, it is thought that the intention of the second sentence is that a thread should be able to lock and unlock a priority ceiling mutex without the implicit yield that any resulting priority changes would normally cause as a side effect.

Since these statements are creating exceptions to the normal scheduling rules, it would be better to state them in the same place as those rules instead of on the pthread_mutexattr_getprotocol() page.

Also, there are problems with the related rationale in B.2.8.4, namely that it conflicts with the normative text and with itself regarding when the head of a ready list is removed, and it still only talks about processes whereas the normative text has been updated to talk about threads.
Desired Action Delete the quoted paragraph.

After page 508 line 17723 section 2.8.4, add a new paragraph:
While a thread is executing at a temporarily elevated priority as a consequence of owning a mutex initialized with the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol (see [xref to pthread_mutexattr_getprotocol()]), the effects of the above requirements on thread priority shall apply only to the thread's normal priority, not to its elevated priority, and those of the above requirements that describe the thread being placed on any thread list as a result of a priority change shall not apply. Likewise, when such a thread reverts to its normal priority as a consequence of unlocking such a mutex, those of the above requirements that describe the thread being placed on any thread list as a result of a priority change shall not apply.

On page 3610 line 122991 section B.2.8.4, change:
relevant to process scheduling; see also [xref to B.2.9.4].
to:
relevant to process and thread scheduling; see [xref to B.2.9.4] for additional rationale relevant to thread scheduling.

On page 3610 line 122992 section B.2.8.4,
and page 3611 line 122993,122997,123001 section B.2.8.4, change:
processes
to:
processes or threads

On page 3611 line 122999 section B.2.8.4, change:
process sequencing
to:
process and thread sequencing

On page 3611 line 123005 section B.2.8.4, change:
In an operating system supporting multiple concurrent processes, the system determines the order in which processes execute and might force long-running processes to yield to other processes at certain intervals. Typically, the scheduling code is executed whenever an event occurs that might alter the process to be executed next.
to:
In an operating system supporting multiple concurrent processes or threads, the system determines the order in which threads (including those that are the only thread in a single-threaded process) execute and might force long-running threads to yield to other threads at certain intervals. Typically, the scheduling code is executed whenever an event occurs that might alter the thread to be executed next.

On page 3611 line 123009 section B.2.8.4, change:
Whenever a process becomes runnable, it is placed on the end of a ready list. 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.
to:
Whenever a thread becomes runnable, it is placed on the end of a ready list. When processing resources become available, the thread at the front of the ready list starts or resumes execution and is removed from the list. This thread is executed until it exits or becomes blocked, at which point the processing resources used to execute it become available to execute another runnable thread.

On page 3611 line 123015-123029 section B.2.8.4, change all occurrences of "process[es]" to "thread[s]".

On page 3611 line 123020 section B.2.8.4, change:
Further, if a process elects to alter its priority, it is removed from the ready list and reinserted, using its new priority, according to the policy above.
to:
Further, if a running or runnable thread's priority is altered, it is removed from the ready list for its old priority (if present in the list; that is, not running) and is inserted into the ready list for its new priority, according to the policy above, except that threads executing at a temporarily elevated priority as a consequence of owning a mutex initialized with the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol are exempted from this in order to ensure that a thread can lock and unlock such as mutex without the implicit yield that any resulting priority changes would normally cause.

On page 3611 line 123031 section B.2.8.4, change:
all processes are well-behaved realtime applications
to:
all threads belong to well-behaved realtime applications

On page 3611 line 123034 section B.2.8.4, change:
POSIX.1-2017 specifies a linear scheduling model. In this model, every process in the system has a priority. The system scheduler always dispatches a process that has the highest (generally the most time-critical) priority among all runnable processes in the system. As long as there is only one such process, the dispatching policy is trivial. When multiple processes of equal priority are eligible to run, they are ordered according to a strict run-to-completion (FIFO) policy.
to:
For process scheduling, POSIX.1-202x specifies a linear scheduling model. In this model, every process in the system has a priority. The system scheduler always dispatches a process that has the highest (generally the most time-critical) priority among all runnable processes in the system. As long as there is only one such process, the dispatching policy is trivial. When multiple processes of equal priority are eligible to run, they are ordered according to a strict run-to-completion (FIFO) policy. Thread scheduling is similar, except that the scheduling policy can be applied just to the threads within one process (PTHREAD_SCOPE_PROCESS scheduling contention scope) or to all threads system-wide (PTHREAD_SCOPE_SYSTEM scheduling contention scope). This and other considerations specific to thread scheduling are the subject of [xref to B.2.9.4]; the remainder of this section is described in terms of process scheduling but is also relevant to thread scheduling when read in conjunction with [xref to B.2.9.4].

Tags tc3-2008
Attached Files

- Relationships

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2022-10-21 08:07 geoffclare New Issue
2022-10-21 08:07 geoffclare Name => Geoff Clare
2022-10-21 08:07 geoffclare Organization => The Open Group
2022-10-21 08:07 geoffclare Section => pthread_mutexattr_getprotocol()
2022-10-21 08:07 geoffclare Page Number => 1687
2022-10-21 08:07 geoffclare Line Number => 55047
2022-10-21 08:07 geoffclare Interp Status => ---
2022-10-24 15:11 Don Cragun Status New => Resolved
2022-10-24 15:11 Don Cragun Resolution Open => Accepted
2022-10-24 15:11 Don Cragun Tag Attached: tc3-2008
2022-11-08 14:18 geoffclare Status Resolved => Applied


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker