Re: POSIX threads scheduling policy/priority

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Stathis Kamperis <ekamperi%gmail.com@localhost> wrote:
> 
> POSIX says that the threads that are unblocked by
> pthread_cond_broadcast() shall contend for the mutex according to the
> scheduling policy (if applicable), and as if each had called
> pthread_mutex_lock().
> 
> My question is whether we can safely assume that the first thread to
> wakeup will be the high priority thread. Or, if this is not the case,
> whether the high priority thread will preempt the low priority as soon
> as the former wakes up. Mind that the threads may be running in
> different CPUs.

If pthreads implementation claims priority scheduling support, then POSIX
requires to behave by scheduling policy.  Term "wakeup" is tricky i.e.
removing from the sleep queue, adding to the run queue and actually running
are three different things.  It is expected that highest priority thread
will run first.  Multiprocessor system has certain corner cases which we
currently do not guarantee for real-time threads.

> My ultimate goal is to come up with a test that performs some kind of
> Q/A regarding thread priorities. Any ideas would be highly appreciated
> and attribution given where due.

Very good goal, considering support for real-time applications.  However,
we do not yet support priority protection (e.g. priority inheritance) for
pthreads.  It is one of few planned things for better real-time support.

-- 
Mindaugas