[Gc] FYI for GC users on multi-threaded apps
hans.boehm at hp.com
Thu Jun 10 17:29:44 PDT 2010
I don't think thread-local allocation should be an issue.
I think there are some platform-specific issues with the GC properly tracing through pointers stored in thread-local variables. If you need to use thread-local data to hold pointers to the garbage-collected heap, it's much safer to also store a copy of the pointer someplace else, where the collector can find it more easily. The problem is that most operating systems don't provide a good way for the collector to enumerate thread-local data.
The thread-local data used by the collector itself should be fine, since the collector knows where that is.
> -----Original Message-----
> From: gc-bounces at linux.hpl.hp.com
> [mailto:gc-bounces at linux.hpl.hp.com] On Behalf Of Tracy Brown
> Sent: Tuesday, June 08, 2010 9:51 PM
> To: Ivan Maidanski
> Cc: gc at linux.hpl.hp.com
> Subject: RE: [Gc] FYI for GC users on multi-threaded apps
> Honestly, I had only experimented with enabling posix threads
> on the configure script. It was an interesting exercise for
> me since what I had implemented was very experimental and the
> resulting architecture change had no peformance impact - if
> anything it helped.
> Actually the thread specific data stuff was a generalization.
> What I had been doing was very odd and experimental and in a
> perfect world, should have worked. I looked at the source for
> GC and couldn't easily figure on a proper reason for my
> particular issue. I have a hunch it's TSD related but the way
> GC operates, it aborts when debug is enabled before the
> application would normally experience failure. I just figured
> you guys are really good and have code to deduce a sequence
> of evens leading into such as TSD style failure.
> And really, I have no idea if I'm close to correct. I'm just
> grateful to have such a facility available to the public.
> From: Ivan Maidanski [ivmai at mail.ru]
> Sent: Tuesday, June 08, 2010 9:02 PM
> To: Tracy Brown
> Cc: gc at linux.hpl.hp.com
> Subject: Re: [Gc] FYI for GC users on multi-threaded apps
> As for BDWGC, thread-local memory is used only if -D
> Tue, 8 Jun 2010 12:55:09 -0700 Tracy Brown <tbrown at perfnet.com>:
> > I've been debugging a daemon where I had implemented GC and
> discovered (though obvious now that I know) that you cannot
> use GC in a multi-threaded environment where you dispatch to
> another thread and that other thread returns a result that is
> allocated dynamically. There may be application specific
> reasons as to why this is the case for me but the short
> answer is that GC uses thread specific memory that isn't
> accessible to another thread. If there's any vestige of truth
> to this, maybe someone can elaborate and make a note in the
> usage docs. As for me, I altered my dispatching architecture
> to retain GC. Hope this helps someone somewhere avoid a little grief.
> > Cheers,
> > Tracy Steven Brown
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc