Re: PATCH: Provide runtime intialization of _STL_mutex_lock class (revised)

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <200106121914.PAA21930@hiauly1.hia.nrc.ca>,
"John David Anglin" <dave@hiauly1.hia.nrc.ca> 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):

struct _STL_mutex_lock
 {
 // GCC extension begin
 #if defined(__STL_GTHREADS)
+  // 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).

Regards,
Loren