Really poor named_semaphore performance in Windows

[Josh Davidson <josh.davidson@…>]

I'm experiencing performance issues using named semaphores on Windows 7 x64. Currently, I'm on 1.49 beta 1, but the behavior was similar on 1.48 and 1.47. Below, I'm copying two sets of sample programs. They simply synchronize with one another using a pair of semaphores. To run them, start the first program and then the second. They will synchronize with each other 100k times and then the second program will spit out the elapsed time. You can restart the second program to run again without bringing down the first program. One set uses boost::interprocess named_semaphores. The second uses native win32 api to demonstrate the difference.

On Windows, the elapsed time the first time around is anywhere from 20 - 40 seconds. If you leave the second program running, the following run will be only about 2-3 seconds. A third run it will be back up to 20-40 seconds, and it will keep bouncing back and forth like that. The pure Windows implementation completes in only 250ms (up to 160x faster). On Linux, the total elapsed time is consistently less than half a second.

Something is up. Wrapping the native semaphores shouldn't slow them down this drastically. Also, the fact that the performance bounces around is another indication that something is seriously wrong.

[Josh Davidson <josh.davidson@…>]

Native Windows (1 of 2)

[Josh Davidson <josh.davidson@…>]

Native Windows (2of 2)

[Josh Davidson <josh.davidson@…>]

Boost (1 of 2)

[Josh Davidson <josh.davidson@…>]

Boost (2 of 2)

[Ion Gaztañaga]

We could not reproduce it with the latest version so closing it as fixed.