Another RT issue Mark K. Gardner (14 Apr 2000 16:40 UTC)
Re: Another RT issue Marc Feeley (15 Apr 2000 02:45 UTC)
Re: Another RT issue Mark K. Gardner (17 Apr 2000 15:24 UTC)

Re: Another RT issue Marc Feeley 15 Apr 2000 02:45 UTC

> 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.