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

[Mark Terribile]

The following reply was made to PR threads/151767; it has been noted by GNATS.

From: Mark Terribile <materribile at yahoo.com>
To: David Xu <davidxu at freebsd.org>
Cc: freebsd-gnats-submit at 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