Re: EINVAL when SCHED_OTHER thread tries to hold PTHREAD_PRIO_PROTECT mutex

[Sripathi Kodi <sripathik at in dot ibm dot com>]

Hi Carlos,

On Thursday 27 March 2008 20:20, Carlos O'Donell wrote:
> Sripathi Kodi wrote:
> > I have a program where a SCHED_OTHER thread tries to hold a
> > pthread_mutex_t initialized with the PTHREAD_PRIO_PROTECT protocol.
> > This fails with an EINVAL. Using strace/ltrace, I found that the
> > sched_setscheduler, internally called by pthread_mutex_lock returns
> > EINVAL, because it tries to set the priority of the thread to a
> > value not permissible for SCHED_OTHER.
>
> This is probably because the kernel doesn't allow SCHED_OTHER
> processes to have any priority other than 0? Have you tried using
> SCHED_RR?

Yes, that's correct. It works fine if the thread is either SCHED_RR or 
SCHED_FIFO. However, when it is a SCHED_OTHER thread, trying to set 
it's priority in the range 0-99 fails as expected. 

I need to know whether pthread_mutex_lock returning EINVAL is an 
acceptable behavior in this circumstance. Manpages/POSIX are not very 
clear about this.

Ulrich, could you please comment on this?

PRIO_INHERIT mutexes don't have this problem because glibc doesn't make 
explicit sched_setscheduler call, everything is handled in the kernel. 
I am not sure if kernel is handling the policy correctly, though.

Thanks,
Sripathi.

>
> Cheers,
> Carlos.