[Gc] External thread suspend and resume
hans.boehm at hp.com
Tue Jul 20 15:11:53 PDT 2010
I remember a bit, but probably not all, of the history here. There are strong arguments for and against this:
This is a dangerous and very easy to misuse interface. Programmers tend to use it for things they shouldn't. If you asynchronously suspend a thread and then call a library routine that happens to acquire a lock that happened to be held by the suspended thread you deadlock. In fact, it's not clear there are any correct use cases for conventional client code, as a result of this problem.
There seem to be good reasons certain other system software really needs it. This includes some debugging tools. It may also include a java runtime trying to implement java.lang.Thread.suspend/resume, which are deprecated for the above reason, but haven't actually been removed. Such code should probably be using a GC-provided facility, since the GC needs to know which threads are suspended; otherwise the GC is likely to deadlock.
I think Mono added something similar, mostly for debugging reasons, and this code might even have come from there.
I think I'd be inclined to add this. If we want to document it in gc.h, it should come with a disclaimer that it is deadlock prone, and should be used only by very low-level code that does not call into libraries acquiring unknown locks. This would unfortunately require porting the code to a recent GC version.
> -----Original Message-----
> From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
> On Behalf Of Dmitrijs Ledkovs
> Sent: Tuesday, July 20, 2010 12:16 PM
> To: Ivan Maidanski
> Cc: gc at linux.hpl.hp.com
> Subject: Re: [Gc] External thread suspend and resume
> 2010/7/20 Ivan Maidanski <ivmai at mail.ru>:
> > Mon, 19 Jul 2010 17:41:29 +0100 Dmitrijs Ledkovs
> <dmitrij.ledkov at ubuntu.com>:
> >> Next up in gcc svn 114869 and 124081 GC_suspend_thread and
> >> GC_resume_thread have been implemented.
> >> Again I can't seem to find similar looking code in cvs head. Please
> >> evaluate weather this functionality should be ported over.
> > Yes, there is no present in bdwgc. See my previous post. Is this
> really needed for gcc? If yes, please provide a patch against the
> current bdwgc cvs.
> Thanks. Will evaluate further whether it is used at all and whether it
> should be ported to head.
> >> Combined cleaned up patch is attached.
> >> (as with previous patches these are patches within the gcc tree and
> >> might not apply cleanly against cvs head)
> > Thanks.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc