Use of the information contained in this unapproved document is at your own risk
.Last update: 30 March,1998
1003.1c-95 #20 _____________________________________________________________________________ Interpretation Number: XXXX Topic: protocol attribute etc Relevant Sections: 13.6.1.2 Interpretation Request: (Defect Report) ----------------------- Date: Tue, 16 Jul 1996 16:05:56 -0700 From: "Scott J. Norton" <sjn@hpwssjn.cup.hp.com> 1) Section 13.6.1.2, page 128-129 D10, lines 581-587 What is the default value of the protocol attribute? 2) Section 13.6.1.2, 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 functons 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) Section 13.6.1.2, 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? Interpretation response ------------------------ This is a duplicate. See PASC P1003.1c Interpretation #3, part 8. Rationale ------------- None. Forwarded to Interpretations group: July 17th 1996 Finalised: Sep 4 1996