Date: Wed, 27 Oct 2010 02:50:04 GMT From: Mark Terribile <materribile@yahoo.com> To: freebsd-threads@FreeBSD.org Subject: Re: threads/151767: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail Message-ID: <201010270250.o9R2o4xb095190@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR threads/151767; it has been noted by GNATS. From: Mark Terribile <materribile@yahoo.com> To: David Xu <davidxu@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201010270250.o9R2o4xb095190>