[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another RT issue

This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 are here. Eventually, the entire history will be moved there, including any new messages.

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