Co oznacza atomic::is_lock_free?

Witam
Przeczytałem na ten temat kilkanaście artykułów w necie ale nic z tego nie rozumiem. Może dlatego że na początku założyłem, że template atomic<T> to to samo co gdy masz zmienną typu T + mutex, tylko że w tym drugim wypadku przed każdym użyciem zmiennej (read/write) musisz manualnie wywołać mutex.lock/unlock() a w atomic domyślam się że już pod spodem to jest wywoływane. I z takim założeniem być może dlatego mam problem ze zrozumieniem po co ta metoda i co ona oznacza. Np. mamy opis:

All atomic types except for std::atomic_flag may be implemented using mutexes or other locking operations, rather than using the lock-free atomic CPU instructions. Atomic types are also allowed to be sometimes lock-free, e.g. if only aligned memory accesses are naturally atomic on a given architecture, misaligned objects of the same type have to use locks.

The C++ standard recommends (but does not require) that lock-free atomic operations are also address-free, that is, suitable for communication between processes using shared memory.

Nawet na polski nie potrafię tego sobie przetłumaczyć o czym oni powyżej mówią. Pierwsze słysze że jest jakaś asemblerowa intrukcja lock-free atomic. Dalej to już jakaś czarna magia. Z góry dzięki za objaśnienie jak ktoś kuma po co jest is_lock_free. Np. był tam przykład że ta klasa :

struct B { int x, y; };
atomic<B>

jest is_lock_free. Czyli jak metoda zwraca mi true to oznacze że w ogóle nie potrzebuje opakowywać zmiennej w template atomic i w ogóle nie potrzebuje mutexa dla niej?

Jest możliwość, że CPU/OS w standardzie mają thread-safe operacje na pewnych typach danych. Przykładowo, x86 gwarantuje, że obiekt z domyślnym aligmentem do 8 4 bajtów będzie miał lock-free support (dla x86_64 jest to 8 bajtów). Znaczy to np, że nie ma żadnego mutexa w std::atomic<int> na x86 (jeśli jeszcze OS to wspiera). Generalnie lockowanie jest operacją czasochłonną i sporo optymalizacji masz w standardzie, coby nie używać tylu mutexów. Żeby było jasne - nie zwalnia Cię to nigdy z obowiązku pisania std::atomic<T> zamiast T.
"założyłem, że template atomic<t> to to samo co gdy masz zmienną typu T + mutex"
To jest nieprawda zupełna, bo po pierwsze nigdzie nie masz napisane, że zapewnienie thread-safety odbywa się za pomocą mutexa, a po drugie - jak wyżej - często masz sporo optymalizacji na poziomie CPU.
Przykład z cppreference.com: https://wandbox.org/permlink/2J4OpZnS0ZHfhGxh

ok rozumiem, czyli lepiej używać atomic<T> niż zmiennej i dedykowanego dla niego mutexa bo wtedy być może na pewnych architekturach CPU kod będzie wykonywał się szybciej gdyż to biblioteka std zadecyduje już czy mutex (bądź inna forma synchronizacji międzywątkowej) należy użyć bądź nie.

No powiedzmy. Drugi powód jest taki, że Ty sie sto razy pomylisz z tym std::mutex, a biblioteka standardowa raczej nie.