On Thu, Mar 6, 2014 at 5:10 PM, Chris Jones <notifications@github.com>wrote:

> In EventFilter/Utilities/plugins/FastMonitoringService.h:
>
> > -					<< std::endl;
> > -
> > -			// lock the monitor
> > -			fmt_.monlock_.lock();
> > -			fmt_.m_data.macrostateJ_ = fmt_.m_data.macrostate_;
> > -			fmt_.m_data.ministateJ_ = encPath_.encode(fmt_.m_data.ministate_);
> > -			fmt_.m_data.microstateJ_ = encModule_.encode(
> > -					fmt_.m_data.microstate_);
> > -
> > -			fmt_.m_data.jsonMonitor_->snap(true, fastPath_);
> > -			fmt_.monlock_.unlock();
> > -
> > -			//::sleep(1);
> > -			::sleep(sleepTime_);
> > -		}
> > +	std::atomic_thread_fence(std::memory_order_acquire);
>
> By the way, I'm afraid using a sleep to deal with synchronization problems
> is only postponing the problem. If the CPU pauses one thread longer than
> your sleep you get the data race problem again. In everything I've read and
> done the only way is to properly synchronize.
>

I fully agree with this. For this reason I ended up putting fences.

 --
> Reply to this email directly or view it on GitHub<https://github.com/cms-sw/cmssw/pull/2661/files#r10347664>
> .
>