std::mutex bug: Windows handle growth
Corinna Vinschen
corinna-cygwin@cygwin.com
Tue Mar 17 14:08:19 GMT 2026
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
More information about the Cygwin
mailing list