[Bug libstdc++/46455] shared_ptr consuming too many semaphores on Windows

["redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.11.15 14:13:00
     Ever Confirmed|0                           |1

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-11-15 14:13:00 UTC ---
(In reply to comment #9)
> 
> this code produces the same behavior as my test case (increasing number of
> semaphores, over 100 after 10 seconds) on both vanilla MinGW and mingw64.
> 
> to summarize: my test case (standard shared_ptr creation) worked fine on
> mingw64 (which has a __gnu_cxx::__default_lock_policy = 2) but bugged on
> vanilla MinGW (which has a __gnu_cxx::__default_lock_policy = 1); but this one
> produces the bug in both cases.

That's because my simpler test ignores the default_lock_policy, it always uses
a mutex, which is what shared_ptr does when __default_lock_policy=1

I've just looked at __gnu_cxx::__mutex and it doesn't have a destructor, so the
problem is probably just that we leak the mutex. This should show the same bug:

#include <ext/concurrence.h>

int main()
{
    for (int i=0; i<100; ++i)
        __gnu_cxx::__mutex m;
}

Could you test that?

We should add a destructor to __mutex, which calls __gthread_mutex_destroy. 

N.B. this could cause a problem on FreeBSD
http://www.freebsd.org/cgi/query-pr.cgi?pr=150889
so we might want to only call __gthread_mutex_destroy when we have used
__GTHREAD_MUTEX_INIT_FUNCTION