This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] libstdc++/16248
- From: Mohan Embar <gnustuff at thisiscool dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: per at bothner dot com, dannysmith at users dot sourceforge dot net, bkoz at redhat dot com
- Date: Fri, 02 Jul 2004 00:37:27 -0500
- Subject: Re: [v3] libstdc++/16248
- Reply-to: gnustuff at thisiscool dot com
Hi People,
(I didn't know whether to append this to the Bugzilla report
or post this here....)
Concerning this:
http://gcc.gnu.org/ml/libstdc++/2004-07/msg00002.html
...I agree that the patch is much cleaner and simpler
than my rough draft:
http://gcc.gnu.org/ml/libstdc++/2004-06/msg00384.html
(which is not quite right because some #defines are in
the wrong place). The only question I have concerns the
lazy mutex initialization vs. the eager initialization
as discussed in the Bugzilla report. My proposal was
kludgy because it attempted to preserve the lazy initialization
semantics of the Win32 gthread_once formalism, whereas the simpler
patch goes for eager initialization, bypassing gthread_once. Among
other things, this means that CreateSemaphore will be called in static
initializers.
One of Per's observations in the Bugzilla report was
(concerning an initial idea of his) was: "My solution of doing the
initialization eagerly is cleaner, and makes lock marginally
faster. However, start-up time is obviously very important,
which argues for lazily initializing the mutex using something
like the "once" mechanism."
Not knowing who the intended consumers of mutex_type
are, I don't know whether I'm making a big deal about nothing
or whether this is a valid concern....
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/