From owner-freebsd-threads@FreeBSD.ORG Wed Oct 27 02:50:05 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14874106566C for ; Wed, 27 Oct 2010 02:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E70588FC0C for ; Wed, 27 Oct 2010 02:50:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9R2o4N1095191 for ; Wed, 27 Oct 2010 02:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9R2o4xb095190; Wed, 27 Oct 2010 02:50:04 GMT (envelope-from gnats) Date: Wed, 27 Oct 2010 02:50:04 GMT Message-Id: <201010270250.o9R2o4xb095190@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Mark Terribile Cc: 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: Mark Terribile List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 02:50:05 -0000 The following reply was made to PR threads/151767; it has been noted by GNATS. From: Mark Terribile To: David Xu Cc: freebsd-gnats-submit@freebsd.org Subject: Re: threads/151767: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail Date: Tue, 26 Oct 2010 19:27:29 -0700 (PDT) =0ADavid,=0A=0A> Mark Terribile wrote:=0A ...=0A> > 1) A pthread_mutexattr_= t is initialized and then=0A> parameters are set.=A0 Some are unsupported o= r invalid,=0A> as shown below.=A0 All the operations return success.=0A ...= =0A> > 2) The pthread_mutex_attr_t is used in the=0A> initialization of a p= thread_mutex_t.=A0 The=0A> pthread_mutex_init returns success.=0A ...=0A> >= 3) A subesequent operation (pthread_mutex_lock,=0A> pthread_mutex_destroy)= on the mutex in question returns=0A> EINVAL.=0A=0A> Long time ago, I had r= eported the priority issue in ULE=0A> scheduler,=0A> the scheduler incorrec= tly changed a time-sharing thread to=0A> real-time=0A> priority when it ret= urns to userland if it thinks it is=0A> interactive.=0A> so you can not use= prority protected mutex with ULE=0A> scheduler.=0A> see sched_ule.c:=0A=0A= David,=0A=0AThis isn't a critical problem for me. I ran into it while chec= king=0Amy own error-handling code. It's always a tricky business to MAKE= =0Athings go wrong to test it.=0A=0AAnd I have no problem with the priority= protected mutex being unavailable=0A(though others might). The problem fo= r me is that the initialization=0Asuceeds, but then every subsequent operat= ion fails. If you have code that=0Aassumes that a failure in pthread_mutex= _destroy() means a very sick=0Aprogram, you'll react the wrong way to an er= ror of this sort. And tracing=0Ait to the source cost me most of a day, ev= en though I was doing nothing=0Abut testing some wrappers on pthreads.=0A= =0ASo while this error is officially non-critical, it can cost a great deal= =0Aof time. It is a bizarre failure-at-a-distance for parameters that can= =0Aand should be checked--and probably are, but maybe not completely enough= .=0A=0ABut it's good to know that it reflects an underlying problem whose r= oot=0Acause is known. Thanks for explaining it.=0A=0A Mark Terribile=0A= =0A=0A