Причина почему там не 2 всегда в другом

Причина в том, что в один момент может быть x == true и y == false. sequential consistency гарантирует, что из read_x_then_y и read_y_then_x всегда будет виден этот порядок

Нет. Есть такой порядок:

write_x
read_x_then_y
write_y
read_y_then_x

read_x_then_y не будет инкрементить.

write_x
read_x_then_y
write_y
read_y_then_x

Да, и вправду. Спасибо. Ладно, всё, что я скажу по итогу, так что описание join()-а в этой книге некорректно.
С другой стороны, если бы join() был именно таким, никакой гонки не было бы и запись true в обе переменные произошла бы до чтения. Впрочем, да, спишем всё на гонку

Если ты про связь join-а со скоупом, то да, это фигня

Там на скоуп влияние только в плане "если не вызвать Join, то будет terminate в деструкторе std::thread при выходе из скоупа"

Но это другое

Есть необходимость иметь уникальный айдишник для некоторых типов чтобы их можно было сравнивать в рантайме, что-то вроде std::type_index.
Требования:
- переносимость не нужна (т.е. достаточно чтобы решение работало на одном компиляторе)
- поддержка полиморфных типов не нужна
- стандарт C++03 (т.е. std::type_index нельзя, он AFAIK только в 11ом появился)
- RTTI отключен (вроде как без него typeid() тоже не работает)
- читабельные имена типов и прочие плюшки не обязательны, достаточно чтобы тайп-айди был уникальным и его можно было сравнивать с другими тайп-айди

Пока смотрю на следующие трюки:
1. Адрес статического метода шаблонного класса, типа template<typename T> struct TypeInfo { static void get() {} };.
2. Шаблонная функция + макрос типа __PRETTY_FUNCTION__ который сгенерит строку для нее + адрес на эту строку. AFAIK именно этот трюк используется в boost:typeindex для ctti.
3. Какой-нибудь статический счетчик для типов.

Какие подводные камни у трюков выше? Что чатик может посоветовать?

Если кол-во типов ограничено и небольшое, то думаю достаточно просто нафигачить специализацию шаблона на каждый тип.
Если нужно больше универсальности, то вариант использовать boost::typeindex самый адекватный

Кол-во типов таки потенциально неограниченно. Можно конечно делать специализации на каждый тип, но не хотелось бы.

А какие явные минусы 1го и 3го подходов?

Ну я  не вижу в них  универсальности

А не, я просто не понял их

В варианте 1 надо ещё доказать, что мы имеем право сравнивать указатели на функции

Мне это не очевидно

Вариант 3 я не понял

Через динамические либы работает только способ номер 2, если есть dll boundary то выбор очевиден.

Я сейчас глянул реализацию std::any в gcc - там именно такой подход и используется в кишках std::any_cast. У каждого типа есть статический метод _S_manage, каждый std::any хранит его как _M_manager, в кишках std::any_cast они сравниваются.

Идея в том, что где-то хранится статический счетчик, при каждом вызове getTypeInfo<T>() он увеличивается и сохраняется в другую статическую переменную для этого T

Вот это хорошее замечание, спасибо

Ну, это не аргумент в общем случае