The default 'blind' prior is a simple exponential expectation whereby
we assume for any given duration of waiting 't', that the expected
completion time is 2t; i.e. we expect to wait as long as we have
already been waiting. As such, the optimum time to start with the
'sleep(1)' strategy (which from my tests sleeps for a full 20ms
timeslice) is after 20ms, (only after which point the prior leads us
to assert that the completion will probably take at least another
20ms).
In my patch, I found the 20ms 'optimum' value to be considerably
higher than 1000, and that was on hardware circa 2010.
Gav.
On 21 August 2013 08:07, Ion Gaztañaga
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost