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

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

php - Nothing but 'run(); ' when browsing to my local project, how do I fix this? -

php - How can I echo out this array? -