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<interprocess_mutex> lock(sm_control_sync->mutex); while (1) { sm_control_sync->cond_running.notify_one(); sm_control_sync->cond_timestep.wait(lock); ns_common::TimeProfile_Periodic (&sm_io->status.control_sync, &sync_first, &sync_time); Control_PWM (); if (control_run) { Control_Run (); control_run = FALSE; } else { control_run = TRUE; } ns_common::TimeProfile_Execution (&sm_io->status.control_sync, &sync_first, &sync_time); } } Plant process has the same sort of thing DWORD __stdcall Plant_Sync (LPVOID) { scoped_lock<interprocess_mutex> lock(sm_plant_sync->mutex); while (1) { sm_plant_sync->cond_running.notify_one(); sm_plant_sync->cond_timestep.wait(lock); ns_common::TimeProfile_Periodic (&sm_io->status.plant_sync, &sync_first, &sync_time); Plant_Run (); ns_common::TimeProfile_Execution (&sm_io->status.plant_sync, &sync_first, &sync_time); } } And then main process counts down a multiplier to increase it's run rate. In this case 10000X boost::interprocess::scoped_lock<boost::interprocess::interprocess_mutex> plant_lock(plant_sync.mutex); boost::interprocess::scoped_lock<boost::interprocess::interprocess_mutex> control_lock(control_sync.mutex); mult = 10000; if(mult > 1) { iterations = 0; while(mult-- > 0) { plant_sync.cond_timestep.notify_one(); control_sync.cond_timestep.notify_one(); plant_sync.cond_running.wait(plant_lock); control_sync.cond_running.wait(control_lock); iterations++; } } 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! Jeffrey Noll Software Engineer (860)654-6378 CONFIDENTIALITY WARNING: This email may contain privileged or confidential information and is for the sole use of the inteded recipients. Unauthorized disclosure or use of this communication is prohibited. If you believe that you have received this email in error, please notify the sender immediately and delete it from your system.
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 <windows.h>. Does it make it any better? -sh
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 <windows.h>. 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 <windows.h>. Does it make it any better? -sh --<-- The function call instructs the kernel to run at context switch HZ that's appropriate for demanding tasks. Be sure to use it when appropriate. Hopefully it's fine to try to help through private email. cheers, -sh
participants (5)
-
Ion Gaztañaga
-
Lars Viklund
-
Niall Douglas
-
Noll, Jeffrey T UTAS
-
Stanisław Halik