IEEE Standards Interpretations for IEEE Std 1003.1c™-1995 IEEE Standard for Information Technology--Portable Operating System Interface (POSIX(R)) - System Application Program Interface (API) Amendment 2: Threads Extension (C Language)
Copyright © 1996 by the Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street New York, New York 10017 USA All Rights Reserved.
Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.
IEEE Standards Department, Copyrights and Permissions, 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA
Interpretation Request #20
Topic:protocol attribute etc Relevant Clauses: 18.104.22.168
1) Clause 22.214.171.124, page 128-129 D10, lines 581-587
What is the default value of the protocol attribute?
2) Clause 126.96.36.199, page 128-129 D10, lines 578-580, 595-606 PTHREAD_PRIO_PROTECT This states that a) the priority of the locking thread shall raise its priority to the mutex prioceiling and b) that prioceiling must be a valid priority for SCHED_FIFO. What happens if the locking thread is not SCHED_FIFO? Chances are pretty good that the prioceiling value is not a valid priority for the scheduling policy of the thread. Even if the thread is SCHED_RR the value may not be valid. Do these functions imply that you must also change the scheduling policy of the locking thread to SCHED_FIFO? If so, what happens if the system defines SCHED_FIFO to have lower priorities than say SCHED_RR and the thread is under SCHED_RR?
3) Clause 188.8.131.52, page 128-129 D10, lines 590-594 PTHREAD_PRIO_INHERIT This states that the blocking thread shall raise the priority of the thread owning the mutex to equal that of the blocking thread. Only the priority is being changed here. What happens if the threads are in different scheduling policies? The new priority may not be valid in that scheduling policy. Is it assumed that these functions also change the policy of the thread if they are different?
This is a duplicate. See Interpretation #3, parts 8, 9, and 10.
Rationale for Interpretation