This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: EINVAL when SCHED_OTHER thread tries to hold PTHREAD_PRIO_PROTECT mutex


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]