Managing quality of service (QoS) in an operating system can be done in a number of ways. At one extreme one can make hard real time guarantees to the applications, refusing to run them if the hard real time guarantees cannot be made. At the other extreme one can hope for the best by providing more resource than one expects to be used.
In between are a range of options which are more appropriate for multimedia systems. In general the approach is to provide probabilistic guarantees and to expect applications to monitor their performance and adapt their behaviour when resource allocation changes.
Some QoS architectures, for example [3] assume a context in which applications specify their QoS requirements to a layer below them which then determines how that requirement is to be met and in turn specifies derived QoS requirements to the next layer below. This is a particularly bad approach when the layers are performing multiplexing (e.g. a single thread operating on behalf of a number of applications) since great care must be taken to prevent QoS crosstalk. Even when the processing is not multiplexed we cannot escape the need to have a recursive mapping of QoS requirements down the service stack. This is not a practical approach; providing this mapping is problematic, particularly when the application itself is unlikely to understand its QoS requirements, and when they change in time.