This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: EINVAL when SCHED_OTHER thread tries to hold PTHREAD_PRIO_PROTECT mutex
- From: Sripathi Kodi <sripathik at in dot ibm dot com>
- To: "Carlos O'Donell" <carlos at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, drepper at redhat dot com
- Date: Thu, 27 Mar 2008 20:45:27 +0530
- Subject: Re: EINVAL when SCHED_OTHER thread tries to hold PTHREAD_PRIO_PROTECT mutex
- References: <200803201646.24836.sripathik@in.ibm.com> <47EBB425.9030909@codesourcery.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.