This is the mail archive of the
mailing list for the libstdc++ project.
Re: PATCH: Provide runtime intialization of _STL_mutex_lock class (revised)
- To: dave at hiauly1 dot hia dot nrc dot ca
- Subject: Re: PATCH: Provide runtime intialization of _STL_mutex_lock class (revised)
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Date: Tue, 12 Jun 2001 17:59:29 -0500 (CDT)
- CC: bkoz at redhat dot com, gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- References: <200106121914.PAA21930@hiauly1.hia.nrc.ca>
- Reply-to: rittle at labs dot mot dot com
In article <200106121914.PAA21930@hiauly1.hia.nrc.ca>,
"John David Anglin" <email@example.com> writes:
> 4) Added an additional call to __gthread_once after the global lock has been
> obtained to try to further ensure that the initialization of _M_lock works
> correctly on multiprocessor systems.
I am happy with everything except adding a __gthread_once_t to a
struct that might be an automatic (note that _STL_mutex_lock is used
in _STL_auto_lock which is clearly intended for that use):
// GCC extension begin
+ // The class must be statically initialized with __STL_MUTEX_INITIALIZER.
+#if !defined(__GTHREAD_MUTEX_INIT) && defined(__GTHREAD_MUTEX_INIT_FUNCTION)
+ int _M_init_flag;
+ __gthread_once_t _M_once;
In pthread_once(3) on FreeBSD, I see this:
The behavior of pthread_once() is undefined if once_control has automatic
storage duration or is not initialized by PTHREAD_ONCE_INIT.
_Programming with POSIX threads_ by David R. Butenhof has a similar
warning on pg 132 regarding the fact that pthread_once_t must be
statically initialized (in the C sense).