[Gc] about gc and pthread_win32 (and GC7.0alpha9, thread-local allocation)

Boehm, Hans hans.boehm at hp.com
Tue May 15 13:06:14 PDT 2007

I made the changes in the repository.  See near the top of the pthreads
section in include/private/gc_locks.h for some new macros that will have
to be adapted on platforms that use non-numeric thread ids.  If Romano
or someone else wants to submit a patch to really make this work for
Mingw, that would be great.

I also made this available as GC7.0alpha9, which is a current snapshot
of the repository.  As far as I know, it's in pretty good shape.  The
only significant 6.8 regression I found while testing on half a dozen or
so platforms is that parallel marking is currently broken on PA-RISC

If someone wants to try thread-local allocation on Windows, I believe
that should also now work with an autoconf-based Cygwin build, or with a

The file name for 7.0alpha9 changed a bit, since I'm now using "make
dist" to generate the distribution.  It's now called


(There is a minor known glitch, in that some of the CVS files are making
it into the distribution.  This shouldn't have any adverse affect other
than wasting space.)

The repository version was bumped to 7.0alpha10 to avoid confusion.
Alpha7 and alpha9 are well-defined and suitably tagged, while alpha8 and
alpha10 describe various in-between repository versions.


> -----Original Message-----
> From: Romano Paolo Tenca [mailto:rotenca at telvia.it] 
> Sent: Tuesday, May 15, 2007 10:16 AM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] about gc and pthread_win32
> Boehm, Hans ha scritto:
> > Good point.  It really should not make that assumption.  
> The down side 
> > is that there are serious difficulties with not making it, since I 
> > need to be able to hash on it, and I need to be able to generate an 
> > invalid thread id.  Also Linux seems to use a function call 
> for pthread_equal.
> >
> > Based on a quick web search, it looks to me like the 
> hashing problem 
> > is unavoidable, and this really can't be done portably without 
> > inventing a replacement notion of thread id.  Thus I'm inclined to 
> > just invent platform-dependent macros for (a) thread comparison 
> > (usually integer comparison, but pthread_equal where 
> needed) and (b) 
> > mapping pthread_t to an identifying integer.  (Multiple threads may 
> > have the same associated identifying integer, though that should be 
> > rare.)
> >
> > Does that sound plausible?
> >   
> Yes to me.
> I made something like that for 6.7 (where the problem was 
> almost only the use of pthread_equal)
> > This would need to be completed and checked by someone like 
> you with 
> > easy access to a platform that uses a struct as pthread_t.
> >   
> I can test it under Mingw. (I need a makefile.direct. 
> Configure does not work well in my system for unknown reasons).
> In gc 6.7 most of Cygwin code for pthread works well under mingw and
> win32 ptread. The main problem was a new set of configure 
> macro (i used something like GC_WIN32_PTHREAD) to use the 
> same pthread code under Cygwin and Mingw.
> > Hans
> >
> >   
> -- 
> Romano Paolo Tenca

More information about the Gc mailing list