Windows: condition_variable::notify_one consumes semaphore handles

[henri.hakonen@…]

When condition_variable receives lot of notify_one-calls, it reserves many semaphore handles. Test program consumes over 30 handles per second in my computer.

[henri.hakonen@…]

Test program

[henri.hakonen@…]

Handles

[viboes]

I've no access to a Windows machine. Please, could you count the number of notify_one per second?

[viboes]

See #11457

[harris.pc@…]

A note, perhaps not useful, but regardless:

I thought I had a handle leak in my program on windows 7/10, so I used this test code to try out this particular possibility.

I tested the attached code test with Boost 1.60.0 + MSVC2010, and it worked as expected - ie no handle leak.

And now I can't seem to reproduce the problem in my program. So I can't be sure if it was just a windows quirk that has magically gone away.

Sorry I don't have something more useful to share

[henri.hakonen@…]

It seems that problem is gone now when I test with boost 1.67.0. There is no leak anymore.

I think that this problem was specific to boost 1.65.0. My quick fix was to comment one line in condition_variable.hpp. (here X: (upper) is my version of 1.65.0 and E: (lower) is original boost.

X:\boost\thread\win32>fc condition_variable.hpp e:\prj\boost_git\libs\thread\include\boost\thread\win32\condition_variable.hpp Comparing files condition_variable.hpp and E:\PRJ\BOOST_GIT\LIBS\THREAD\INCLUDE\BOOST\THREAD\WIN32\CONDITION_VARIABLE.HPP * condition_variable.hpp

              // do it here to avoid throwing on the destructor
              //entry->remove_waiter();
              locker.lock();

* E:\PRJ\BOOST_GIT\LIBS\THREAD\INCLUDE\BOOST\THREAD\WIN32\CONDITION_VARIABLE.HPP

              // do it here to avoid throwing on the destructor
              entry->remove_waiter();
              locker.lock();

*

[viboes]

Thanks for the information.

Already fixed.