<

Interpretations

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

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 © 1997 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 #17
Topic: pthread_attr_setschedparam Relevant Clauses: 13.5.1.2

These functions do not provide for an EPERM error condition. All other scheduling functions have an EPERM to signify that the user doesn't have permission to set these particular scheduling attributes. Similarly, pthread_create() also does not contain an EPERM. This behavior requires implementations to let anyone use the SCHED_FIFO/SCHED_RR policies and priorities, even though all other functions trying to use them may return EPERM. What is the correct behavior? Are there supposed to be EPERM error returns for these functions? Should there be an error of EPERM for pthread_create() instead? Should all three functions have an EPERM error return?

Interpretation Response
The standard is clear that setting the scheduling policy or priority values in the scheduling attribute object does not actually change the value for any threads. It is only when the attribute object is used in a pthread_create that the parameters are used and it is at that time that the parameters shall be consistent. The scheduling policy and priorities of an existing thread may be changed using the pthread_setschedparm function which requires both a policy and a priority. The standard is silent on what permissions, if any, an application must have to perform a pthread_create. Conforming implementations are free to not restrict access or to restrict access and return EPERM if detected. Conforming applications must handle this case.

Rationale for Interpretation
It is not possible to detect or report EPERM error conditions when modifying the scheduling parameter attributes. The intent was that attributes objects may be thought of as user data structures, and the various set and get functions might be nothing more than macros that assign (or read) data to or from members of that structure.