threads/151767: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail

Daniel Eischen deischen at
Wed Oct 27 02:26:43 UTC 2010

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.


More information about the freebsd-threads mailing list