From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6076 invoked by alias); 26 Aug 2013 18:41:58 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 6052 invoked by uid 89); 26 Aug 2013 18:41:58 -0000 Received: from popelka.ms.mff.cuni.cz (HELO popelka.ms.mff.cuni.cz) (195.113.20.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Aug 2013 18:41:58 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_NEUTRAL autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: popelka.ms.mff.cuni.cz Received: from domone.kolej.mff.cuni.cz (popelka.ms.mff.cuni.cz [195.113.20.131]) by popelka.ms.mff.cuni.cz (Postfix) with ESMTPS id E238017F57; Mon, 26 Aug 2013 20:41:50 +0200 (CEST) Received: by domone.kolej.mff.cuni.cz (Postfix, from userid 1000) id B2C5F5FC15; Mon, 26 Aug 2013 20:41:50 +0200 (CEST) Date: Mon, 26 Aug 2013 18:41:00 -0000 From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= To: Rich Felker Cc: Carlos O'Donell , Torvald Riegel , GLIBC Devel , libc-ports Subject: Re: [PATCH] Unify pthread_once (bug 15215) Message-ID: <20130826184150.GA8772@domone.kolej.mff.cuni.cz> References: <1368024237.7774.794.camel@triegel.csb> <519D97E4.4030808@redhat.com> <20130826124955.GA6065@domone.kolej.mff.cuni.cz> <20130826164507.GA20515@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130826164507.GA20515@brightrain.aerifal.cx> User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2013-08/txt/msg00047.txt.bz2 On Mon, Aug 26, 2013 at 12:45:07PM -0400, Rich Felker wrote: > On Mon, Aug 26, 2013 at 02:49:55PM +0200, Ondřej Bílka wrote: > > On Thu, May 23, 2013 at 12:15:32AM -0400, Carlos O'Donell wrote: > > > On 05/08/2013 10:43 AM, Torvald Riegel wrote: > > > > Note that this will make a call to pthread_once that doesn't need to > > > > actually run the init routine slightly slower due to the additional > > > > acquire barrier. If you're really concerned about this overhead, speak > > > > up. There are ways to avoid it, but it comes with additional complexity > > > > and bookkeeping. > > > > > > We want correctness. This is a place where correctness is infinitely > > > more important than speed. We should be correct first and then we > > > should argue about how to make it fast. > > > > > As pthread_once calls tend to be called once per thread performance is > > not an issue. > > No, pthread_once _calls_ tend to be once per access to an interface > that requires static data to have been initialized, so possibly very > often. On the other hand, pthread_once only invokes the init function > once per program instance. I don't see anything that would typically > happen once per thread, although I suppose you could optimize out > calls to pthread_once with tls: > Could happen often but dees it? Given need of doing locking you need to avoid it in performance critical code. With once per thread I meant an patterns: computation(){ pthread_once(baz,init); // Do common initialization. pthread_create(foo,bar,routine); } or pthread_create(foo,bar,routine); with routine() { pthread_once(baz,init); // Do common initialization. ... } > static __thread int once_done = 0; > static pthread_once_t once; > if (!once_done) { > pthread_once(&once, init); > once_done = 1; > } > > This requires work at the application level, though, and whether it's > a net advantage depends a lot on whether multiple threads are likely > to be hammering pthread_once on the same once object, and whether the > arch has expensive acquire barriers and inexpensive TLS access. > Actually you can use following if you are concerned about that use cases: #define pthread_once2(x,y) ({ \ static __thread int once = 0; \ if (!once) \ pthread_once(x,y); \ once=1; \ }) > Rich