Re: POSIX threads scheduling policy/priority

[Stathis Kamperis <ekamperi%gmail.com@localhost>]

2009/10/16 Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>:
> Hello,
>
> Stathis Kamperis <ekamperi%gmail.com@localhost> wrote:
>> I've written a test case regarding POSIX threads scheduling policy &
>> priority. The test is here:
>> http://gitweb.dragonflybsd.org/~beket/pcca-tests.git/blob_plain/master:/pthread.h/t_pthread_attr_setschedpolicy.c
>>
>> For some reason, I can't set the policy/priority of {hi, low}_thread
>> from the main thread. In NetBSD 5.0_STABLE that is. The setter
>> function report success, but the threads are born with the default
>> values for their attributes. Linux fails as well, whereas Solaris 10 +
>> dflybsd-current pass.
>
> Scheduling attributes can be inherited (PTHREAD_INHERIT_SCHED) or set
> explicitly (PTHREAD_EXPLICIT_SCHED), see pthread_attr_setinheritsched()
> description.  POSIX allows any default, in NetBSD it's inherit.
>
> Also, keep in mind that 0 and 1 priority values in your test case may not
> necessary be valid priority numbers (although it is very unlikely).  It can
> be any range, only required condition by POSIX is that it should provie at
> least 32 levels.  To determine min/max, there are sched_get_priority_min()
> and sched_get_priority_max() calls.
>
> --
> Mindaugas
>

Thanks Mindaugas! I've fixed both issues (attribute inheritance,
min/max priorities) and now it works ok under NetBSD!

I had some off-list discussions on a more general note regarding the
reliability of the test and a question emerged.

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.

In this sense, I have been advised to use a more probabilistic
approach. E.g., have the 2 threads bound in the same CPU (is there a
standard way to do it ? guess not) to busy-loop and then measure how
far they have advanced.

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.



Best regards,
Stathis