As long as Qr is non-empty, the sdom at the head is due some contracted time and should be run. If Qr becomes empty, the scheduler has fulfilled all its commitments to sdoms until the head of Qw becomes runnable. In this case, the scheduler can opt to run some sdom in Qw for which x is true, i.e. one which has requested use of slack time in the system. Domains are made aware of whether they are running in this manner or in contracted time by a flag in their DCB.
The current policy adopted by the scheduler is to run a random element of Qw for a small, fixed interval or until the head of Qw becomes runnable, whichever is sooner. Thus several sdoms can receive the processor ``optimistically'' before Qr becomes non-empty. The best policy for picking sdoms to run optimistically is a subject for further research. The current implementation allocates a very small time quantum (122 µs) to a member of Qw picked cyclically. This works well in most cases, but there have been situations in which unfair `beats' have been observed.