threads/150889: PTHREAD_MUTEX_INITIALIZER + pthread_mutex_destroy () == EINVAL

[John Baldwin]

On Friday, September 24, 2010 11:37:53 am Jung-uk Kim wrote:
> On Friday 24 September 2010 09:26 am, John Baldwin wrote:
> > On Thursday, September 23, 2010 11:48:40 pm Jung-uk Kim wrote:
> > > On Thursday 23 September 2010 06:44 pm, Daniel Eischen wrote:
> > > > You shouldn't have to call pthread_mutex_init() on a mutex
> > > > initialized with PTHREAD_MUTEX_INITIALIZER.  Our implementation
> > > > should auto initialize the mutex when it is first used; if it
> > > > doesn't, I think that is a bug.
> > >
> > > Ah, I see.  I verified that libthr does it correctly.  However,
> > > that's a hack and it is far from real static allocation although
> > > it should work pretty well in reality, IMHO.  More over, it will
> > > have a side-effect, i.e., any destroyed mutex may be resurrected
> > > if it is used again.  POSIX seems to say it should return EINVAL
> > > when it happens. :-(
> >
> > I think the fix there is that we should put a different value
> > ((void *)1 for example) into "destroyed" mutex objects than 0 so
> > that destroyed mutexes can be differentiated from statically
> > initialized mutexes.  This would also allow us to properly return
> > EBUSY, etc.
> 
> It would be nice if we had "uninitialized" as (void *)0 and "static 
> initializer" as (void *)1.  IMHO, it looks more natural, i.e., 
> "uninitialized" or "destroyed" one gets zero, and "dynamically 
> initialized" or "statically initialized" one gets non-zero.  Can we 
> break the ABI for 9, maybe? ;-)

I actually find the (void *)1 more natural for a destroyed state FWIW.
One thing I would advocate is that regardless of the values chosen,
use constants for both the INITIALIZER and DESTROYED values.  That would make 
the code more obvious.  In general I think your patch in your followup is 
correct, but having explicitly DESTROYED constants that you check against 
instead of NULL would improve the code.

-- 
John Baldwin