On Thu, Mar 6, 2014 at 4:10 PM, Srecko Morovic <Srecko.Morovic@cern.ch>wrote:

>
>
>
> 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).
>
>
Hmm, I misunderstood that you were referring to another place where fence
is used.
Yes, this one could be replaced by std::atomic<>.

Cheers,
Srecko



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