boost 153 interprocess_mutex much slower in windows 7 than xp?
We have 3 processes that are synchronized with an interprocess mutex. Basically one of them has a multiplier which allows the others to run at a synchronized accelerated rate. Under XP we typically can get it to run at 5000 times realtime. New desktop refreshes are coming out running Windows 7 and the same code with faster machines with more memory are maxing out at 250 times with 95%+ cpu idle time.
Am new to boost so am wondering if we're doing something wrong. Here's the crux of the code. 3 processes and some shared memory.
Share memory defines
struct ds_control_sync
{
boost::interprocess::interprocess_mutex mutex; //Mutex to protect access to the queue
boost::interprocess::interprocess_condition cond_running; //Condition to wait when the control software is running
boost::interprocess::interprocess_condition cond_timestep; //Condition to wait until the control software is to run again
};
struct ds_plant_sync
{
boost::interprocess::interprocess_mutex mutex; //Mutex to protect access to the queue
boost::interprocess::interprocess_condition cond_running; //Condition to wait when the plant software is running
boost::interprocess::interprocess_condition cond_timestep; //Condition to wait until the plant software is to run again
};
Control process has a thread that waits for a signal to run once.
DWORD __stdcall Control_Sync (LPVOID)
{
scoped_lock
Noll, Jeffrey T UTAS wrote:
Works great under XP, our new Windows 7 desktops it are dog slow by a factor of around 50. Any ideas why this would be? Thanks!
Do a "(void) timeBeginUpdate(1);" at the top of main(), including
On Mon, Oct 07, 2013 at 06:15:50PM +0200, Stanisław Halik wrote:
Noll, Jeffrey T UTAS wrote:
Works great under XP, our new Windows 7 desktops it are dog slow by a factor of around 50. Any ideas why this would be? Thanks!
Do a "(void) timeBeginUpdate(1);" at the top of main(), including
. Does it make it any better?
I assume you mean timeBeginPeriod, http://msdn.microsoft.com/en-us/library/windows/desktop/dd757624(v=vs.85).as... -- Lars Viklund | zao@acc.umu.se
On 7 Oct 2013 at 14:26, Noll, Jeffrey T UTAS wrote:
Works great under XP, our new Windows 7 desktops it are dog slow by a factor of around 50. Any ideas why this would be?
Sounds like your spin count needs adjusting. Newer CPUs are much better at doing lock xchg than older machines - hence your spin count needs increasing on newer machines. (As an aside, Linux's glibc very seriously needs to increase its spin counts on its pthreads mutex as it's a serious constraint on ASIO's maximum throughput on Linux - FreeBSD and Windows runs rings around it. It's far too low for modern CPUs. Yes the bug report is already submitted). Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
El 07/10/2013 16:26, Noll, Jeffrey T UTAS escribió:
We have 3 processes that are synchronized with an interprocess mutex. Basically one of them has a multiplier which allows the others to run at a synchronized accelerated rate. Under XP we typically can get it to run at 5000 times realtime. New desktop refreshes are coming out running Windows 7 and the same code with faster machines with more memory are maxing out at 250 times with 95%+ cpu idle time.
Am new to boost so am wondering if we're doing something wrong. Here's the crux of the code. 3 processes and some shared memory.
It might be due to Windows scheduler changes between XP and 7. Interprocess mutexes have generally very big context-switch overhead. This has been fixed for soon to be release Boost 1.55. You can try to see if this is your problem changing the boost/interprocess/detail/win32_api.hpp. Replace Sleep(1) with Sleep(0) and see if your tests are improving. In that case you can try Sleep(0) but your CPU usage will increase a lot, or try Boost 1.55 beta to see if this definitely fixes the issue. best, Ion
Noll, Jeffrey T UTAS wrote:
We have 3 processes that are synchronized with an interprocess mutex. Basically one of them has a multiplier which allows the others to run at a synchronized accelerated rate. Under XP we typically can get it to run at 5000 times realtime. New desktop refreshes are coming out running Windows 7 and the same code with faster machines with more memory are maxing out at 250 times with 95%+ cpu idle time.
Sorry for replying through email, but my response wasn't accepted by the mailing list moderator, apparently... Here's the original message that I've tried sending to the list: -->-- Noll, Jeffrey T UTAS wrote:
Works great under XP, our new Windows 7 desktops it are dog slow by a factor of around 50. Any ideas why this would be? Thanks!
Do a "(void) timeBeginUpdate(1);" at the top of main(), including
participants (5)
-
Ion Gaztañaga
-
Lars Viklund
-
Niall Douglas
-
Noll, Jeffrey T UTAS
-
Stanisław Halik