multithreading - Why only std::atomic_flag is guaranteed to be lock-free? -


from c++ concurrency in action:

difference between std::atomic , std::atomic_flag std::atomic may not lock-free; implementation may have acquire mutex internally in order ensure atomicity of operations

i wonder why. if atomic_flag guaranteed lock-free, why isn't guaranteed atomic<bool> well? because of member function compare_exchange_weak? know machines lack single compare-and-exchange instruction, reason?

first of all, allowed have std::atomic<very_nontrivial_large_structure>, std::atomic such cannot guaranteed lock-free (although specializations trivial types bool or int could, on systems). unrelated.

the exact reasoning why atomic_flag , nothing else must be lock-free given in note in n2427/29.3:

hence operations must address-free. no other type requires lock-free operations, , hence atomic_flag type the minimum hardware-implemented type needed conform standard. the remaining types can emulated atomic_flag, though less ideal properties.

in other words, it's minimum thing must guaranteed on every platform, it's possible implement standard correctly.


Comments

Popular posts from this blog

Email notification in google apps script -

c++ - Difference between pre and post decrement in recursive function argument -

javascript - IE11 incompatibility with jQuery's 'readonly'? -