Date: Fri, 24 Sep 2010 11:37:53 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: Daniel Eischen <deischen@freebsd.org>, freebsd-threads@freebsd.org Subject: Re: threads/150889: PTHREAD_MUTEX_INITIALIZER + pthread_mutex_destroy () == EINVAL Message-ID: <201009241137.56764.jkim@FreeBSD.org> In-Reply-To: <201009240926.12958.jhb@freebsd.org> References: <201009232220.o8NMK3fX011639@freefall.freebsd.org> <201009232348.45201.jkim@FreeBSD.org> <201009240926.12958.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? ;-) Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009241137.56764.jkim>