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

From: Carlos O'Donell <carlos at codesourcery dot com>
To: Sripathi Kodi <sripathik at in dot ibm dot com>
Cc: libc-alpha at sourceware dot org
Date: Mon, 31 Mar 2008 16:43:17 -0400
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> <200803272045.27475.sripathik@in.ibm.com>

Sripathi Kodi wrote:

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.

POSIX says "The scheduling parameters for the SCHED_OTHER policy are implementation-defined," and the Linux Kernel says "SCHED_OTHER may have only priority 0," thus *any* call which attempts to change your threads priority will fail.

I think this behaviour is acceptable.

Cheers,
Carlos.
--
Carlos O'Donell
CodeSourcery
carlos@codesourcery.com
(650) 331-3385 x716

References:
- EINVAL when SCHED_OTHER thread tries to hold PTHREAD_PRIO_PROTECT mutex
  - From: Sripathi Kodi
- Re: EINVAL when SCHED_OTHER thread tries to hold PTHREAD_PRIO_PROTECT mutex
  - From: Carlos O'Donell
- Re: EINVAL when SCHED_OTHER thread tries to hold PTHREAD_PRIO_PROTECT mutex
  - From: Sripathi Kodi

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