[PATCHES][RFC] Fix a deadlock bug in static variable initialization

[Richard Guenther]

On 08 Jun 2007 14:52:42 -0700, Ian Lance Taylor <iant@google.com> wrote:
> "Richard Guenther" <richard.guenther@gmail.com> writes:
>
> > On 6/8/07, Doug Kwan (êPÕñµÂ) <dougkwan@google.com> wrote:
> > > Hi,
> > >
> > >     Attached here is patches to both gcc and libstdc++-v3 to fix a
> > > deadlock problem in function static variables. The patches have been
> > > applied to gcc-4.1.0 and tested on i486 with a full bootstrap. I've
> > > also test the trunk it is not stable enough to do a full bootstrap.
> >
> > Care to explain the deadlock problem?
>
> The explanation is in the patch.
>
> Ian
>
> +// Here are C++ run-time routines for guarded initiailization of static
> +// variables. There are 4 scenarios under which these routines are called:
> +//
> +//   1. Threads not supported (__GTHREADS not defined)
> +//   2. Threads are supported but not enabled at run-time.
> +//   3. Threads enabled at run-time but __gthreads_* are not fully POSIX.
> +//   4. Threads enabled at run-time and __gthreads_* support all POSIX threads
> +//      primitives we need here.
> +//
> +// The old code supported scenarios 1-3 but was broken since it used a global
> +// mutex for all threads and had the mutex locked during the whole duration of
> +// initlization of a guarded static variable. The following created a dead-lock
> +// with the old code.
> +//
> +//     Thread 1 acquires the global mutex.
> +//     Thread 1 starts initializing static variable.
> +//     Thread 1 creates thread 2 during initialization.
> +//     Thread 2 attempts to acuqire mutex to initialize another variable.
> +//     Thread 2 blocks since thread 1 is locking the mutex.
> +//     Thread 1 waits for result from thread 2 and also blocks. A deadlock.
> +//
> +// The new code here can handle this situation and thus is more robust. Howere,
> +// we need to use the POSIX thread conditional variable, which is not supported
> +// in all platforms, notably older versions of Microsoft Windows. The gthr*.h
> +// headers define a symbol __GTHREAD_HAS_COND for platforms that support POSIX
> +// like conditional variables. For platforms that do not support conditional
> +// variables, we need to fall back to the old code.

Hm, ok.  So I guess you can quote me another part of the patch that
explains the solution? ;)

Richard.