bug report (with fix): pthread_setschedparam() fails withWindows-CE 3.0 (Pocket PC)

[Tristan Savatier <tristan at mpegtv dot com>]

I just discovered a bug in pthread_win32 that caused
pthread_setschedparam() to fail systematically with
Windows-CE 3.0 (dubbed Pocket PC by microsoft).

The bug stems from the following piece of code that seems
perfectly correct at first sight:

====================================================
int pthread_setschedparam(pthread_t thread, int policy,
			  const struct sched_param *param)
{
[...]

  /* Validate priority level. */
  if (param->sched_priority < sched_get_priority_min(policy) ||
      param->sched_priority > sched_get_priority_max(policy))
    {
      return EINVAL;
    }

[...]
}

int sched_get_priority_min(int policy)
{
  if (policy < SCHED_MIN || policy > SCHED_MAX)
    {
      return EINVAL;
    }

  /* This is independent of scheduling policy in Win32. */
  return THREAD_PRIORITY_LOWEST;
}

int sched_get_priority_max(int policy)
{
  if (policy < SCHED_MIN || policy > SCHED_MAX)
    {
      return EINVAL;
    }

  /* This is independent of scheduling policy in Win32. */
  return THREAD_PRIORITY_HIGHEST;
}

====================================================

On Windows98, THREAD_PRIORITY_LOWEST is (-2) and 
THREAD_PRIORITY_HIGHEST is 2, and everything works just fine.

On WinCE 3.0, it so happen that THREAD_PRIORITY_LOWEST is 5
and THREAD_PRIORITY_HIGHEST is 1 (yes, I know, it is funny:
highest priority use smaller numbers) and the following happens:

sched_get_priority_min() returns 5
sched_get_priority_max() returns 1

and of course:

pthread_setschedparam() always fails to validate priority
level and returns EINVAL!!!

I believe that the correct fix is something like:

====================================================

int sched_get_priority_min(int policy)
{
  if (policy < SCHED_MIN || policy > SCHED_MAX)
    {
      return EINVAL;
    }

  /* This is independent of scheduling policy in Win32. */
  return MIN(THREAD_PRIORITY_LOWEST, THREAD_PRIORITY_HIGHEST);
}

int sched_get_priority_max(int policy)
{
  if (policy < SCHED_MIN || policy > SCHED_MAX)
    {
      return EINVAL;
    }

  /* This is independent of scheduling policy in Win32. */
  return MAX(THREAD_PRIORITY_LOWEST, THREAD_PRIORITY_HIGHEST);
}

====================================================

Of course the question remains whether it is 'legal' or
not to have an inverted priority, where the highest priority
is the smalest value.

The book "Multithreaded Programming with Pthread" by Bill Lewis & al.
says (p. 77):

<< POSIX gives no advice on how to use the
priority levels provided.  All you know is that for any given
policy, the priority level must be between 
sched_get_priority_min(policy) and
sched_get_priority_max(policy). >>

It does not say if sched_get_priority_min(policy) is always
assumed to be (numerically) smaller than
sched_get_priority_max(policy), but I assume that it is the case,
and obviously the posix_win32 implementation of
pthread_setschedparam() makes the same assumption.


-- 
Regards, -- Tristan Savatier (President, MpegTV LLC)

MpegTV: http://www.mpegtv.com - Tel: (415) 864 6466
                                Fax: (415) 704 3224