[Gc] FYI for GC users on multi-threaded apps
tbrown at perfnet.com
Tue Jun 8 21:51:26 PDT 2010
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 THREAD_LOCAL_ALLOC.
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.
> Tracy Steven Brown
More information about the Gc