"Richard Guenther" <richard.guenther@gmail.com> writes:
> On 6/8/07, Doug Kwan (?振德) <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.