ï~~FREQUENCY SCHEDULING
REALTIME SCHEDULING IN MULTIPROCESSING SYSTEMS
Frode Holm
Department of Computer Science and
Center for Computer Music Composition
University of California
Santa Barbara, CA93106
ABSTRACT
A realtime scheduling method for multipropessing architectures is proposed. The scheduler guarantees that
deadlines and other timing constraints will be met, and each individual process can specify the degree of the
accuracy and latency of its own timing independent of all other processes in the system. This enables the
scheduler to handle a wide range of timing requirements and allows for efficient co-existence of "fast" and
"slow" processes in the same environment.
Both static and dynamic event-processing is supported in a uniform manner, without having to assume
anything about the event-models employed by the clients. Several other advantages compared to previous
mechanisms are also discussed. Based on early experience the scheduler shows promise for easing the task of
managing and maintaining "real time" to a significant degree.
1. INTRODUCTION
The design of musical process models for realtime computation in a multiprocessing
environment is an area of formidable complexity that has received a great deal of attention
in recent years. Central to all such models is the presence of a scheduler of some sort, a
system component that ensures that timing constraints are met. Sometimes the scheduler is
also the provider of timing information to the individual processes.
Over the years (e.g. Abbott 1984, Anderson 1986) it has been recognized that such a
mechanism should:
1. Provide accurate execution/delivery of timed events. These can either be statically
precomputed (as in notelists, scores, envelope breakpoints etc.) or dynamically
generated (as in interactive algorithmic composition).
2. Provide realtime interaction with external processes (e.g. human performers) with a
guarantee of an acceptable response time.
3. Be distributable so that copies can be run locally on each processor in the system.
4. Separate concerns, e.g. the system parameters for timing accuracy, latency and
smoothing should be individually adjustable such that one parameter will not affect
another.
5. Impose as few restrictions on the user's process model as possible.
6. Be usable for a wide range of time granularities.
7. Allow smoothing of sharp peaks in computation loads.
8. Be efficient
To my knowledge no mechanism has yet been proposed that meets all of these
requirements simultaneously. The current proposal will meet some important requirements,
while others are still being researched.
127
0
