This is the mail archive of the
mailing list for the pthreas-win32 project.
Re: Static libraries initialization
- From: Ross Johnson <Ross dot Johnson at homemail dot com dot au>
- To: Ramiro Polla <ramiro at lisha dot ufsc dot br>, Pthreads-Win32 list <pthreads-win32 at sourceware dot org>
- Date: Sat, 26 Apr 2008 10:06:30 +1000
- Subject: Re: Static libraries initialization
- References: <481082AE.firstname.lastname@example.org> <4810ABB9.email@example.com> <4810D5C3.firstname.lastname@example.org> <4811657E.email@example.com>
Ross Johnson wrote:
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.
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.
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.