From owner-freebsd-threads@FreeBSD.ORG Wed Oct 27 02:26:43 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65B6F106564A; Wed, 27 Oct 2010 02:26:43 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1D2DF8FC12; Wed, 27 Oct 2010 02:26:42 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o9R2QfhP024766; Tue, 26 Oct 2010 22:26:41 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Tue, 26 Oct 2010 22:26:41 -0400 (EDT) Date: Tue, 26 Oct 2010 22:26:41 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <201010270200.o9R20JaV043974@freefall.freebsd.org> Message-ID: References: <201010270200.o9R20JaV043974@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: threads/151767: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 02:26:43 -0000 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