EINVAL when SCHED_OTHER thread tries to hold PTHREAD_PRIO_PROTECT mutex

[Sripathi Kodi]

Hi,

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.

PTHREAD_PRIO_INHERIT does not have this problem because the kernel 
controls everything.

I am wondering if this is an accepted behavior. I can't see anything 
convincing in the man pages about this. From the man page of 
pthread_mutex_lock, it can return EINVAL only when: 

 EINVAL The  mutex was created with the protocol attribute having the
value PTHREAD_PRIO_PROTECT and the calling thread’s priority is higher
than the  mutex’s  current  priority ceiling.

Could anyone please shed light on this? Should glibc change the 
scheduling policy of the thread when it tries to hold such a mutex? 

Thanks,
Sripathi.