> The following is from the Priority and Fairness section.
>
> >    When two threads A and B are blocked on a given mutex or condition
> >    variable, and A blocked before B, then
> >     1. if A's priority is not less than B's priority, A will wakeup before
> >        B
> >     2. otherwise, A will wakeup before or after B.
>
> For RT support, the highest priority task should wake up first. If the
> priorities are the same, then it really doesn't matter so I would
> suggest that the thread blocked first wakes first.
>
> Thus to not preclude the future RT-SRFI, the section should read:
>
>   1. The highest priority thread will wake first.
>   2. If multiple threads have the same priority, the first to block
>      will be the first to wake.
>
> Although this does not produce the same schedule of tasks as the above
> definition, I can't envision an application where this behavior is not
> preferable. Perhaps Marc or someone else can give an example of an
> application where blocking order should take precedence over priority
> when it comes to waking a task.

The current specification in the Priority and Fairness section is
sufficiently weak to allow a FIFO implementation, i.e. an
implementation can ignore priorities but not arrival time.  FIFO is
simple to implement and efficient and provides a certain fairness
guarantee, but it is not particularly useful in a real-time context.

A priority queue based implementation which would be useful in
a real-time context is not excluded by the specification.

Your specification requires a priority queue based implementation.
It's the specification I would expect in a RT-SRFI.

Marc