[Gc] Whats the state of thread local storage.

Boehm, Hans hans.boehm at hp.com
Tue Nov 22 17:46:49 PST 2005

In general your best bet is to also add thread local data to a global
data structure, and to use thread local variables as fast ways to access

Using GC_add_roots with the addresses of __thread variables (in each
thread!) probably also works, though I haven't tried it.

The reason the collector doesn't contain better support for this is that
it's hard to find thread locals.  The data structures are very platform
specific, and there is no real way for the collector to track them down.
Suggestions would be appreciated ...


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Lothar Scholz
> Sent: Tuesday, November 22, 2005 5:38 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Whats the state of thread local storage.
> Hello,
> I found an email from october where it was mentioned that 
> pthread_getspecific seems to be not really supported by the 
> garbage collector. Is this correct for macosx, linux, win32, 
> bsd's and solaris ?
> How about variables with the "__thread" declaration keyword 
> that exist on linux/solaris and as "declspec(thread)" on win32.
> Will the gc work correctly if i use "GC_add_roots" and 
> "GC_remove_roots" to tell the gc about the memory area ?
> -- 
> Best regards,
>  Lothar Scholz              mailto:scholz at scriptolutions.com
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com 
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list