Очень интересно

Популярное заблуждение "атомарность = хорошо"  Типичная ошибка

C++ (Qt)
if (writeFlag) {   
 DoSomethng(..);
}

Обычно в multi-threading такие проверки - мертвому припарка. Чтение writeFlag может быть хоть 100 раз атомарно, но если др нитка его пишет - креш. Атомарность гарантирует лишь что текущее/моментальное значение будет прочитано/записано верно, но уже на момент выполнения след команды (начало DoSomethng) значение writeFlag может оказаться уже иным.

Примерим это к данному случаю

C++ (Qt)
if (m_writeFlag) return; 

Что произойдет если m_writeFlag было true а потом моментально стало false (UI изменило)? Ничего плохого (return), ну пропустим след опрос по таймеру т.к. предыдущий не успел. Вот если бы наоборот (было false - стало true) - тогда бы получили по дюнделю. Но в том-то и дело что UI пишет только  false (никогда true).

Предположим даже что запись m_writeFlag НЕ атомарна (напр тип double который в 32-битах может присваиваться как 2 инта). Но если пишется ноль - и такая запись не может изменить текущий "ноль" на "не ноль".

std::atomic

Этот садовый инструмент называется lock-free. С чисто практической, утилитарной точки зрения - да, он заслуживает осуждения именно по причине своей сложности, мозголомности (хотя код и выглядит простым). Ошибиться очень легко, напр

C++ (Qt)
// Главная Нитка использует мапу и после этого сбрасывает флажок
void SomeWindow::SlotNewData( Checker * checker )
{
// обновляем UI используя checker->m_data
// ...
   checker->m_writeFlag = false;
// ..
// здесь чем-то увлекся, забыл и сбросил флажок еще раз
// ..
   checker->m_writeFlag = false;
}

И вот уже очень мерзкий баг который вылезет не сразу

Ну если это "включить"