|
Boost Users : |
Subject: Re: [Boost-users] [atomic] When to load/store
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2013-05-22 11:29:30
On Wed, May 22, 2013 at 11:04 AM, Michael Powell <mwpowellhtx_at_[hidden]>wrote:
> Hello,
>
> I have some thread synchronization to do, probably will end up using
> some sort of internally synchronized cancelation or other state to
> message between parent and child thread.
>
> If the state uses boost::atomic<bool> _canceled, for instance, how do
> I go about setting/getting the value? I am assuming that we do
> something like this:
>
> //To get the value.
> return _canceled.load(boost::memory_order::memory_order_acq_rel);
>
> //To set the value.
> _canceled.store(canceled, boost::memory_order::memory_order_acq_rel);
>
> Using acquire/release to get in, do what we need with the value, and
> get out, type thing.
>
>
In general, use Acquire if you need to *read* _other_ values (memory
locations) as a result of reading this atomic.
ie if _canceled == true means that the _canceledReason is set and you need
to read that, then you need Acquire.
Use Release if you *write* _other_ values that you expect other threads to
read. ie if you set _canceledReason, and then set _canceled.
If in doubt, use the default - sequential consistency.
If in doubt, use locks.
Also think about how the code might evolve - will the next person that
comes in and adds a read/write understand that the memory ordering needs
changing?
Also bearing in mind this is targeting ARM architecture (ARM5 I think).
>
> Also, how complex a value can be protected? Are we talking primitive
> types only? Basic data types like bool, int, float, that sort of
> thing?
>
>
In theory, anything can be made atomic. But only small types (like bool,
int) will be lock-free. Others will use a lock to get the same effect. (At
least that's how std::atomic works, not sure about boost::atomic.)
Tony
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net