ping [PATCH] Fix a deadlock bug in static variable initialization in libsupc++
Doug Kwan (關振德)
dougkwan@google.com
Mon Sep 17 23:30:00 GMT 2007
Hi Jason,
Here is the patch without the skip-list.
-Doug
-----
2007-09-13 Doug Kwan <dougkwan@google.com>
* gcc/gthr-posix.h (__gthread_cond_broadcast, __gthread_cond_wait,
__gthread_cond_wait_recursive, __gthread_self, __gthread_equal):
Add to extend interface for POSIX conditional variables.
(__GTHREAD_HAS_COND): Macro defined to signify support of
conditional variables.
Likewise
* gcc/gthr-single.h (__gthread_cond_broadcast, __gthread_cond_wait,
__gthread_cond_wait_recursive, __gthread_self, __gthread_equal):
Add to extend interface for POSIX conditional variables.
* gcc/gthr.h: Update comments to document new interface.
* libstdc++-v3/include/ext/concurrent.h (class __mutex,
class __recursive_mutex): Add new method gthread_mutex to access
inner gthread mutex.
[__GTHREAD_HAS_COND] (class __concurrence_broadcast_error,
class __concurrence_wait_error, class __cond): Add.
* guard.cc (recurisve_push, recursive_pop): Delete.
(init_in_progress_flag, set_init_in_progress_flag): Add to
replace recursive_push and recursive_pop.
(throw_recursive_init_exception): Add.
(acquire, __cxa_guard_acquire, __cxa_guard_abort and
__cxa_guard_release): [__GTHREAD_HAS_COND] Use a conditional
for synchronization of static variable initialization.
The global mutex is only held briefly when guards are
accessed. [!__GTHREAD_HAS_COND] Fall back to the old code,
which deadlocks.
* testsuite/thread/guard.cc: Add new test. It deadlocks with the
old locking code in libstdc++-v3/libsup++/guard.cc.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs-deadlock-fix.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070917/997e89e3/attachment.txt>
More information about the Gcc-patches
mailing list