Date: Tue, 26 Oct 2010 22:26:41 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: threads/151767: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail Message-ID: <Pine.GSO.4.64.1010262209080.19313@sea.ntplx.net> In-Reply-To: <201010270200.o9R20JaV043974@freefall.freebsd.org> References: <201010270200.o9R20JaV043974@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Oct 2010, David Xu wrote:
>
> Long time ago, I had reported the priority issue in ULE scheduler,
> the scheduler incorrectly changed a time-sharing thread to real-time
> priority when it returns to userland if it thinks it is interactive.
> so you can not use prority protected mutex with ULE scheduler.
> see sched_ule.c:
I think pthread_mutex_lock() on a priority inherit/ceiling
mutex by a thread without sufficient permission (time-sharing)
should either return EPERM(*), or it should ignore the priority
(with an appropriate statement in the man page) when attempting
the mutex operation.
I think it is okay for any thread (with or without sufficient)
permission to initialize the mutex, though. The thread that
initializes the mutex may not be the same thread(s) that use
the mutex, or it may even raise its permissions at a later
point in time (before operating on the mutex).
(*) POSIX says pthread_mutex_lock() should return EINVAL
for a PTHREAD_PRIO_PROTECT mutex where the thread has a
priority higher than the priority ceiling. Given that,
it seems appropriate to return EINVAL for a priority
inheritence mutex.
--
DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1010262209080.19313>