Здравствуйте, okman, Вы писали:

ну вот первый квалифицированный ответ

O>Правила все те же — compiler reordering, hardware reordering.
так вот сложность как раз увидеть здесь реордеринг и проследить как же он влияет на визибилити. ведь непонятно что с чем может поменяться местами. когда описывают проблему с переупорядочиванием. всегда фигурирует как минимум две переменные. здесь же переменная одна — глобальный словарь

O>Если этого не сделать, вызов spawnThread может быть перемещен, например, в начало функции, до заполнения globalMap данными.
я слабо себе представляю законные причины для данного вида переупорядочивания в нашем примере. склоняюсь к тому, что это будет нарушение стандарта, т.к. компилятор должен быть уверен, что данное переупорядочивание не повлияет на логику работу первого потока (? или всего приложения?) (observable behaviour может быть разным)

O>По поводу второго можно не беспокоиться, так как публикация данных для других потоков -
O>это так или иначе установка какого-нибудь флага, то есть, запись в память. В результате
O>получается комбинация store-store, которая эффектам hardware ordering не подвержена.
тут я не понял о каком флаге идет речь и что такое публикация

O>Еще можно заподозрить компилятор в том, что однажды он проявит излишнюю сообразительность и
O>реализует globalMap через регистры, из-за чего другие потоки не увидят данных.
и какие подсказки надо использовать, чтобы словарь все же расшарился между потоками?

O>Все написанное справедливо для IA-32 и AMD64, на других процессорных архитектурах с
O>более "расслабленной" моделью памяти может потребоваться установка хардварного барьера.
я рассматриваю общий случай. в пред. сообщении я уже предложил фикс, используя именно хардварный барьер. хочу разобраться, нужно ли еще что-то и можно ли соптимизировать доступ к словарю во втором потоке