Interpretations

Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

IEEE Standards Interpretation for IEEE Std 1003.1™-2001 IEEE Standard Standard for Information Technology -- Portable Operating System Interface (POSIX®)

Copyright © 2006 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 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 #83
Topic: pthread_mutexattr_setprotocol PTHREAD_PRIO_PROTECT Relevant Sections: XSH pthread_mutexattr_setprotocol

The description of the PTHREAD_PRIO_PROTECT mutex protocol have raised several questions.

1. Is it possible to set up by pthread_setschedparam() or pthread_setschedprio() the priority of the thread while the thread owns a mutex initialized with the PTHREAD_PRIO_PROTECT mutex protocol?

2.1. SHALL pthread_mutex_setprioceiling() fail with EDEADLK if the calling thread already owns the mutex?

2.2. If no, shall the new priority ceiling of the mutex impact the priority of the calling thread?

The description of the PTHREAD_PRIO_PROTECT mutex protocol functions/pthread_mutexattr_setprotocol.html] reads: "When a thread owns one or more mutexes initialized with the PTHREAD_PRIO_PROTECT protocol, it shall execute at the higher of its priority or the highest of the priority ceilings of all the mutexes owned by this thread and initialized with this attribute, regardless of whether other threads are blocked on any of these mutexes or not."

This quotation has as a consequence the following answers:

1. No, it is not. pthread_setschedparam() or pthread_setschedprio() shall fail. What error code is expected? EPERM?

2.1. Yes.
or
2.1. No.
2.2. Yes, in this case the priority of the calling thread shall be adjusted according the new priority ceiling of the mutex.

Is this interpretation correct?

I believe some clarification of the correlation between automatic modifications of the priority of the thread as a result of pthread_mutex_lock() call and explicit modifications of the priority by pthread_setschedparam() call is required.

Interpretation Response
The standard clearly states the requirements,and conforming implementations must conform to this. No change is required.

Responses to specific questions raised are as follows:

Is this interpretation correct? No

1. Yes
2.1 Undefined
2.2. Does not apply

Rationale for Interpretation
The working felt that this is an unambiguous situation.