Date: Wed, 29 Sep 2010 10:42:38 +0000 From: David Xu <davidxu@freebsd.org> To: Jung-uk Kim <jkim@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r213241 - in head: include lib/libthr/thread Message-ID: <4CA3181E.6030000@freebsd.org> In-Reply-To: <201009281829.13253.jkim@FreeBSD.org> References: <201009280457.o8S4vuS9060037@svn.freebsd.org> <201009281202.22555.jkim@FreeBSD.org> <201009281220.12278.jkim@FreeBSD.org> <201009281829.13253.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jung-uk Kim wrote: > On Tuesday 28 September 2010 12:20 pm, Jung-uk Kim wrote: >> On Tuesday 28 September 2010 12:02 pm, Jung-uk Kim wrote: >>> On Tuesday 28 September 2010 09:31 am, John Baldwin wrote: >>>> On Tuesday, September 28, 2010 12:57:56 am David Xu wrote: >>>>> Author: davidxu >>>>> Date: Tue Sep 28 04:57:56 2010 >>>>> New Revision: 213241 >>>>> URL: http://svn.freebsd.org/changeset/base/213241 >>>>> >>>>> Log: >>>>> In current code, statically initialized and destroyed >>>>> object have same null value, the code can not distinguish >>>>> between them, to fix the problem, now a destroyed object is >>>>> assigned to a non-null value, and it will be rejected by some >>>>> pthread functions. PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP is >>>>> changed to number 1, so that adaptive mutex can be statically >>>>> initialized correctly. >>>> Does this fix PR threads/150889 then? >>> It seems it does. >> Unfortunately, it seems to have a regression: >> >> %cat test.c >> #include <pthread.h> >> #include <stdio.h> >> >> static pthread_cond_t static_cond = PTHREAD_COND_INITIALIZER; >> static pthread_mutex_t static_mutex = PTHREAD_MUTEX_INITIALIZER; >> >> int >> main(void) >> { >> >> // pthread_mutex_lock(&static_mutex); >> printf("%d\n", pthread_cond_wait(&static_cond, &static_mutex)); >> pthread_mutex_unlock(&static_mutex); >> >> return (0); >> } >> %cc -o test test.c -pthread >> %./test >> Segmentation fault (core dumped) >> >> pthread_cond_wait(3) had to return EPERM here. :-( > > I realized it is a libthr "feature" to catch real application bugs and > to increase performance by not checking rare conditions, I guess. :-/ > > Sorry for the noise, > > Jung-uk Kim > I think your example is legal, I might add checking back, however, it would return two codes, EINVAL and EPERM.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CA3181E.6030000>