[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

["per at bothner dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From per at bothner dot com  2004-06-29 18:16 -------
Subject: Re:  [3.5 Regression] recent concurrence.h chanes
 breaks mingw bootstrap

membar at gcc dot gnu dot org wrote:

> ------- Additional Comments From membar at gcc dot gnu dot org  2004-06-29 06:20 -------
> I proposed a patch here:
> 
> http://gcc.gnu.org/ml/libstdc++/2004-06/msg00359.html
> 
> ...but don't have a non-hacked-up mainline anymore. If no one gets to this 
> first, I can look at this in a couple of days.

I don't think poiter-vs-reference is the issue.  The question is who
is response for calling the __GTHREAD_MUTEX_INIT_FUNCTION:  Is it done
eagerly during mutex creation, in__glibcxx_mutex_define_initialized,
or is it done lazily, the first time the lock is acquired?  The current
CVS code code attampts to do the latter; your patch (as far as I can
tell) ends up doing neither, which I don't think can be right.

I.e. when does CreateSemaphore get called?  If it gets called eagerly,
then we don't need the "once" functionality, and something like this
should work:

class __glibcxx_mutex : public __gthread_mutex_t
{
   __glibcxx_mutex () { __GTHREAD_MUTEX_INIT_FUNCTION(this); }
};
#  define __glibcxx_mutex_define_initialized(NAME) \
__glibcxx_mutex NAME
# define __glibcxx_mutex_lock(NAME) \
__gthread_mutex_lock(&NAME)

If we want CreateSemaphore to be called lazily things get more
difficult.  We can't use teh existing __gthread_once function,
since that calls a global zero-parameter function.  We can however
crerate a variation of __gthread_once that calls a one-parameter
function, or invokes an object method.  However, that requires
some more extensive changes.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248