This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.
> 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