[Gc] Race condition between thread termination and garbage
collection under Solaris 10/x86
hans.boehm at hp.com
Fri Mar 5 18:16:36 PST 2010
I'm nervous about applying something along these lines. We would end up with a bunch of duplicated code. And I think this introduces some more races, e.g. between threads accessing the thread table while holding the allocation lock, and those accessing it while holding the "solaris threads lock". I also don't think the allocation lock is a pthread_mutex in all configurations. (Check USE_SPIN_LOCK) And I don't think it handles the case of a thread acquiring the allocation lock in a cleanup handler for other reasons.
If we want to do something like this, I'd intercept pthread_exit() and pthread_cancel() like the other pthread primitives, have them set a flag in the appropriate thread structure (with the allocation lock held), and have a stop_world attempt loop until it sees a thread table with none of those bits set. (In the case of pthread_exit() we don't need to do anything if the thread structure is already gone, I think.)
I wish I understood the problem completely. I looked a little more on Linux. Although the deadlock actually seems similar, I didn't seen any blocked signals. I think that avoids further correctness issues, though it may have performance or even termination problems.
I'll bet at the C++ standards meeting next week, where I should at least be able to find a Posix expert ...
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Burkhard Linke
> Sent: Thursday, March 04, 2010 11:41 AM
> To: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Race condition between thread termination
> and garbage collection under Solaris 10/x86
> the former patch introduces a race condition if several
> threads are terminating at the same time (Acquring allocator
> lock while holding thread lock). Revised patch is attached.
More information about the Gc