@ page 53-54 line 2188-2218 section 2.9.4 objection
Problem:
POSIX.1 defines the "Scheduling Allocation Domain" as the set of
processors on which an individual thread can be scheduled at any given
time.
POSIX.1 states that:
- "For application threads with scheduling allocation domains of
size equal to one, the scheduling rules defined for SCHED_FIFO and
SCHED_RR shall be used;"
- "For application threads with scheduling allocation domains of
size greater than one, the rules defined for SCHED_FIFO, SCHED_RR,
and SCHED_SPORADIC shall be used in an implementation-defined
manner."
- "The choice of scheduling allocation domain size and the level of
application control over scheduling allocation domains is
implementation-defined. Conforming implementations may change the
size of scheduling allocation domains and the binding of threads
to scheduling allocation domains at any time."
The problem is that with these semantics, it is only possible to write
strictly conforming applications with realtime scheduling requirements
for single-processor systems. If a multiprocessor platform is used,
there is no portable way to specify static allocation of threads to
processors and, therefore, to get predictable scheduling behavior.
Although there are some special multiprocessor architectures, most
commercial systems are either single-processor or symmetric
shared-memory multiprocessor systems, and for these systems a simple
API can be designed to manage allocation domains. Additional APIs may
be needed for special architectures, but even a simple API represents
a major step forward towards portability.
The standard should have an API for setting the initial allocation
domain of a thread as part of its thread-creation attributes. The new
API should be optional, but it will be mandated in the realtime
profiles so that predictable scheduling can be achieved in
multiprocessors.
It has to be discussed whether an API is necessary or not for
dynamically changing the allocation domain, as not all implementations
support this feature. Most probably, the real-time profiles will not
require this feature.
Some of the existing vendor models are not quite as general and
flexible (orthogonal) as they could be, and a POSIX effort could end
up raising the level of all. One limitation that has been found is
the inability to make threads stay off of a specified processor or
group of processors.
Action:
Add an API for being able to portably set the initial allocation
domain of a thread.
Every major UNIX platform vendor offers multiprocessor platforms, and
has their own set of non-standard APIs (and perhaps shell commands) to
enable and disable processors, to group them in various ways, and to
allow or forbid defined threads of specified processors or groups of
processors. The planned approach is to collect and study these APIs
and shell commands, and come up with a simple model and set of APIs
that can handle all those models.
Without having made the exercise of checking existing APIs, an initial
idea is sketched below to capture the essence of the required
functionality.
Concepts:
define the concept of a scheduling allocation node as an abstract
entity to which threads may be assigned for the purpose of
scheduling. This will usually be a processor, but it may be some
other implementation-defined object such as a virtual processor or
similar.
Change the wording under "scheduling allocation domain" to explain
the model with the new optional thread attributes (see below)
Types:
Define a type for identification of scheduling allocation nodes; it
is an arithmetic type:
pthread_alloc_node_id_t
Define an opaque type for the allocation domain of a thread. It is
defined as an abstract set of allocation node ids:
pthread_alloc_domain_t
New thread attributes:
allocation-domain-mode:
A flag stating whether the allocation domain is
implementation defined-- PTHREAD_ALLOC_SYSTEM (default) or
application defined-- PTHREAD_ALLOC_APP.
allocation-domain:
it is only used if allocation-domain-mode is
PTHREAD_ALLOC_APP
Interfaces:
define operations to portably get allocation node ids:
pthread_alloc_node_id_t pthread_alloc_node_get_min()
pthread_alloc_node_id_t pthread_alloc_node_get_max()
the number of allocation nodes is (max-min+1); the allocation
node min and max may be different for each process; allocation
node ids are a per-process concept and are not comparable
across processes.
define operations for handling allocation domains (modeled after
signal masks):
int pthread_alloc_domain_empty
(pthread_alloc_domain_t *domain)
int pthread_alloc_domain_fill
(pthread_alloc_domain_t *domain)
int pthread_alloc_domain_add
(pthread_alloc_domain_t *domain,
pthread_alloc_node_id_t node)
int pthread_alloc_domain_del
(pthread_alloc_domain_t *domain,
pthread_alloc_node_id_t node)
int pthread_alloc_domain_ismember
(const pthread_alloc_domain_t *domain,
pthread_alloc_node_id_t node)
define operations to set and get the allocation-domain-mode creation
attribute of a thread:
int pthread_attr_setallocdomainmode
(pthread_attr_t *attr, int mode)
int pthread_attr_getallocdomainmode
(const pthread_attr_t *attr, int *mode)
define operations to set and get the allocation-domain creation
attribute of a thread:
int pthread_attr_setallocdomain
(pthread_attr_t *attr,
pthread_alloc_domain_t domain)
int pthread_attr_getallocdomain
(const pthread_attr_t *attr,
pthread_alloc_domain_t *domain)
Note
The requested action may seem too important for a technical
corrigenda. In that case, the POSIX Realtime System Services Working
Group would like to take this action as a work item for a future
amendment to the standard.
|