From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25985 invoked by alias); 26 Apr 2008 00:07:00 -0000 Received: (qmail 25966 invoked by uid 22791); 26 Apr 2008 00:07:00 -0000 X-Spam-Check-By: sourceware.org Received: from bender.grapevine.net.au (HELO bender.grapevine.net.au) (203.129.32.139) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Apr 2008 00:06:36 +0000 Received: from localhost (localhost [127.0.0.1]) by bender.grapevine.net.au (Postfix) with ESMTP id DF864C032C; Sat, 26 Apr 2008 10:06:31 +1000 (EST) Received: from bender.grapevine.net.au ([127.0.0.1]) by localhost (bender.grapevine.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsGKG1G4I14G; Sat, 26 Apr 2008 10:06:31 +1000 (EST) Received: from localhost.localdomain (unknown [121.127.213.230]) by bender.grapevine.net.au (Postfix) with ESMTP id 74701C032A; Sat, 26 Apr 2008 10:06:31 +1000 (EST) Message-ID: <48127206.9060205@homemail.com.au> Date: Sat, 26 Apr 2008 00:07:00 -0000 From: Ross Johnson User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Ramiro Polla , Pthreads-Win32 list Subject: Re: Static libraries initialization References: <481082AE.3030904@lisha.ufsc.br> <4810ABB9.10106@homemail.com.au> <4810D5C3.2070306@lisha.ufsc.br> <4811657E.40608@homemail.com.au> In-Reply-To: <4811657E.40608@homemail.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2008/txt/msg00021.txt.bz2 Ross Johnson wrote: >> >> The overhead of one if()? If the branch prediction sets the if() to >> be unlikely, there should be 1 memory access and 1 cmp function >> overhead. It shouldn't even disturb the instruction pipeline. > Yes, it's almost negligible and I use the same method to initialise > static POSIX mutexes, cond vars, etc., although this one is slightly > worse in that the data isn't necessarily in cache already or local. > IIRC, we need to use an Interlocked routine to compare the value, not > for atomicity necessarily but so that we get the memory barrier > effects right. And I've found that these calls can be relatively slow > due to bus locking. I'm also still assuming that every single routine > needs this overhead, but that may not be necessary in the end. I'll retract my interlocked/memory fence comments - they aren't needed here. I keep forgetting it's just the first quick check, and the second thorough check will only ever be performed once or twice. Ross