On Thu, Mar 6, 2014 at 3:56 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);
>
> Everything I've read/watched about C++11 says you should avoid using
> atomic_thread_fence and instead use std::atomic<> directly.
>

What is the bad side of using it?

Without these fences I was getting a crash in constructor of the service.
(putting a short sleep was also avoiding the crash).
Now I don't remember in detail, but it seemed to be a data race with
constructor finishing initialization of class variables and what another
thread was seeing.

I will try going back to this and work on a version using std::atomic (it
might be that it crashed accessing an atomic variable, though).

Srecko


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