El 21/08/2013 7:39, Marcello Pietrobon escribió:
Thank you for the last fix Ion.
I've run some tests on it and it has improved the performance, but not completely.
Clearly this problem is not limited to your interprocess library so I thought to open a different thread discussion for it: http://boost.2283326.n4.nabble.com/Problems-with-yield-k-workaround-Still-to...
I've done some profiling plus some tests and so it's clear to me that the test program is still slowed down around the ::sleep(1) instruction.
I am personally content with replacing the value 32 with a value above 1000, so the resolution to this is not urgent for me (just to take some pressure of you ;)).
Thanks for the test. It's definitely hard to tell if 1000 will be OK for everyone, as it might depend on the CPU speed or waiter count (in your example there is a lot of waiting between the same two processes, which is not same use case as hundreds of threads waiting for a single resource). There is a *very experimental* support for native synchronization primitives on windows if you comment the line: #define BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION on boost/interprocess/detail/workaround.hpp It tries to create Windows native named semaphores on the fly with a unique name and implements Alexander Terekhov's 8a algorithm to implement a condition variable. I don't know if it could be faster on your application, but it should use less CPU as it does not use busy waiting. Best, Ion