Re: [boost] [Boost.Interprocess] conditions variables get 10 times faster when opening a multiprocess browser

Subject: Re: [boost] [Boost.Interprocess] conditions variables get 10 times faster when opening a multiprocess browser
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2013-08-21 03:07:44

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-too-slow-td4650929.html
>
> 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