your patch

[John David Anglin]

> Threads are hairy.  Cross-platform threads more so.  Unfortunately,

Totally agree.  I have spent a lot of time thinking about this over
the past couple of weeks.

> I do not understand this code very well.  It looks sane enough to me,
> but we need more eyes.
> 
> We definitely need a review from at least one of, and probably
> both of, Loren and Benjamin.  Please look at this very, very carefully
> to convince yourselves that this code is an improvement over what is
> currently there.  Try to think about race conditions, etc.  If this
> is only to fix HPUX 10, think about whether or not this patch
> is likely to screw up on other more common platforms.

The code only changes the behavior of what is there now for systems
that define __GTHREAD_MUTEX_INIT_FUNCTION or at least that is the
intention.  The more common platforms, which have posix threads, define
__GTHREAD_MUTEX_INIT.  I have checked very carefully that there is
no screw up for i686 linux, a platform which uses gthr-posix and
defines __GTHREAD_MUTEX_INIT.

For system that define __GTHREAD_MUTEX_INIT_FUNCTION, the current
code does not initialize the _STL_mutex_lock struct and the code
will malfunction the first time that an attempt is made to lock the
mutex _M_lock.  It is almost impossible for a user to determine
what needs to be initialized and how to do it.

The integration of GTHREADS into v3 was recently done
< http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00325.html >
and this is a follow up to that patch.

Loren and I have had considerable discussion about race conditions
that can arise on multiprocessor systems.  I believe that the issues
have been addressed at least as well as they have been in eh_globals.cc.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)