Subject: Re: [boost] [Boost.Interprocess] conditions variables get 10 times faster when opening a multiprocess browser
From: Gav Wood (boost_at_[hidden])
Date: 2013-08-21 07:14:22
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
In my patch, I found the 20ms 'optimum' value to be considerably
higher than 1000, and that was on hardware circa 2010.
On 21 August 2013 08:07, Ion Gaztañaga <igaztanaga_at_[hidden]> wrote:
> 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
>> Clearly this problem is not limited to your interprocess library so I
>> thought to open a different thread discussion for it:
>> 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
>> 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.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk