[Gc] Threaded GC questions

Travis Griggs tgriggs at key.net
Tue Aug 16 00:06:31 PDT 2005

We have a soft-real time program that uses pthreads and libgc. For the 
most part, we've been really pleased with the performance so far. But 
of late, we've noticed it's possible that some of our threads just seem 
to dead lock. I haven't got a chance to use top/ps/etc, to really check 
out what exactly the thread states are yet... after I read 
<https://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html> and 
<https://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html> though, I 
ended up with a number of things I was hoping to get clarified:

1) Is it sufficient to use a -DGC_THREADS to get the right semantics 
for libgc and pthreads? Or does one still need to worry about having 
the one header file preceed the other? I use debian linux.

2) Mutator threads need to periodically suspend all other threads, it 
sounds like this is done via the use of program wide signal, and 
specialized signal handlers which yield/spin/whatever so that the 
mutator is not disturbed during collection. I'm sure this is fine for 
normal linux scheduling semantics, but what if one is using 
pthread_sched() to make some of the threads sched_rr and/or sched_fifo 
at higher levels. Is there a possibility for priority inversion in this 
case? I'm curious what other signal interactions one can expect as 

3) The mentioned page talks about the thread local allocation strategy. 
Am I right in understanding that when using this, the degree of 
intrathread synchronization is reduced (or is it removed completely?) 
at the expense of slightly higher allocation times. Do I have to use 
both -DTHREAD_LOCAL_ALLOC as well as include gc_local_alloc.h? Or is 
the first enough? Or do I have to actually rebuild the gc lib? Can 
thread_local allocation be mixed with non?

I'd appreciate any insights/suggestions on what the best possible way 
to mate libgc with our program is:

An example instance of our program might be running as many as 10+ 
threads at 4 different priority levels. The lowest level (normal 
pthread scheduling semantics) is where the socket server runs at, 
accepts new connections (creates a thread per) and services outside 
requests. These connections rarely allocate memory, usually a large 
structure or two. Mostly they just facilitate queries against the run 

The next thread level, the first "real time" priority would be where 4 
threads are running at. This is were the high frequency allocation of 
short lived memory is taking place. Lots of little ( < 64 bytes per) 
structures. Each threads is independent of the other. IOW, the 
allocated structures are not used at all between them (this is what 
leads me to believe that the thread local stuff would be a bonus). 
These threads use pthread_cond_vars to synchronize with the higher 
level threads (no known issues with some of the pthread synchronization 
mechanisms and libgc is there?).

Five high level threads run at priorities above even these. They 
basically are user space drivers which interact with data-acquisition 
hardware. These threads allocate nothing. The check for the existance 
of some of the structures allocated dynamically by the interaction 
threads to decide whether to keep running. Other than that, they have 
no interaction with anything GC-ish. They use ring buffers to make 
their raw data available to the GC intense processing threads and need 
to run pretty much interrupted and need to make sure they have low 
latency. We haven't actually had any problems (at least I don't think) 
with latency, or anything like that. I have toyed with hoisting these 
processes out of the program into separate programs and then placing 
the ring buffers in shared memory so there is no GC affect on them at 
all (does shared memory create problems for libgc?).

As I said, any thoughts/suggestions/hints are greatly appreciated. I 
really do love having libgc available. It's made a semi complicated 
problem much easier to deal with. When I'm not working on soft real 
time C programs, I'm working in Smalltalk, and I think I've discovered 
that if I had to pick between bolting on objects to C vs. bolting on GC 
to C, I find the latter is worth more (not that I mind the other part). 
Thanks to all who've made libgc available.

Travis Griggs
One man's blue plane is another man's pink plane.

DISCLAIMER: This email is bound by the terms and conditions described

More information about the Gc mailing list