Re: std::mutex bug: Windows handle growth

Corinna Vinschen via Cygwin <[email protected]>
Newsgroups gmane.os.cygwin
Message-ID <[email protected]>
On Mar 17 09:06, Noel Grandin via Cygwin wrote:
> Hi
> 
> Hazarding a guess here:
> 
> On 3/16/2026 11:39 PM, Frank Eskesen via Cygwin wrote:
> > I've run into a problem that occurs on Cygwin that doesn't occur on Linux
> > systems: When a std::mutex is used, it doesn't clean up a Windows handle that
> > it uses. This sample program demonstrates the problem, failing in under 60
> This code looks suspicious:
> 
>     pthread_mutex::destroy ()
>     {
>       if (condwaits || trylock ())
>         // Do not destroy a condwaited or locked mutex
>         return EBUSY;
> 
> I think it should be
> 
>       if (condwaits || !trylock ())

No, checking trylock() is correct.  pthread_mutex_destroy() must not
destroy a busy mutex.  trylock() returns != 0 if the lock is busy.

Given the implementation of std::mutex is based on pthread_mutex,
Frank's code is wrong, or at least somewhat borderline.  The mutex
should first be unlocked before leaving do_something().

The reason this problem doesn't occur on Linux is the fact that mutexes
are implemented without allocating a system object, so the
pthread_mutex_destroy() function is basically a no-op, after checking if
the lock is busy and returning 0 or EBUSY, whatever is right.


Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.