Boost logo

Boost :

Subject: [boost] boost 153 interprocess_mutex much slower in windows 7 than xp?
From: Noll, Jeffrey T UTAS (jeff.noll_at_[hidden])
Date: 2013-10-07 10:26:32


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk