[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another RT issue
> 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.