mikronМне просто интересно, на каких процессорах ты тестируеш?
Тероретически на Итаниумах таки да, запись/увеличение счётчика не синхонизирует кеш лайнс. На Х86 кеши всегда когерентны. но вроде не всегда на АМД64. У них более слабая модель памяти чем Х86 но более строгая чем на итаниумах. Что за железо?
А то выяснится, что как ты не показывай проблему, у всех интелы :)У меня Core i7.
Во-первых, конкретно в этом коде проблема не в железе, а в JIT. Если вы дизассемблируете этот код, то увидите, что оптимизатор целиком выкосил проверку if (queue.Count > 0), отсюда и зависание.
Во-вторых, вы верно заметили, что на x86 архитектурах как правило применяют достаточно строгую и консервативную модель памяти, которая запрещает реордеринг сторов. Она так и называется - TSO - total store order. Но она не запрещает реордеринг лоадов, поэтому вот такой код (это некая адаптация алгоритма Петерсона) на x86 не работает:


Если вы немного помедитируете над этим кодом, то увидите, что если только одна из переменных runner1WasFirst или runner2WasFirst может быть true, верно? Ну то есть нельзя на бумажке нарисовать такой сценарий, где обе эти переменных будут true.
Однако, x86, в том числе мой Core i7 не гарантирует когерентности кэшей . Поэтому он спокойно может переколбасить код вот так:

И все, ваш код сломан - у вас два бегуна прибежали первым, что невозможно. Хотя TSO сохранен. Более того, точно такой же эффект может возникнуть не только от реордеринга инструкций, но и от того, что кэши всегда становятся когерентными со временем, но не всегда когерентны в моменте. Поэтому один поток может записать флажок, а другой это не увидит. Почитайте про store buffer и invalidate queue на досуге.

Кстати, примерно этот же пример приведен прямо в документации интеловских процессоров. Если очень надо будет - дам вам ссылку.

В любом случае, в рассматриваемом нами некорретном коде от Arm79 проблема не в железе, а в JIT-компиляторе.

mikron,
Нет, кэши не когерентны. Повторюсь - читайте про store buffer и invalidate queue.
Виной тому, что код не останавливается - именно компмлятор, и никто иной. Это сгенерировал такой ассембли, в котором проверка вынесена за цикл. Процессор так делать не умеет, он вообще не знант, что такое «цикл».
Но разумеется, это не «проблема» и не баг. Это ожидаемое поведение. Проблема у нас сейчас только в том, что коллеги Arm79 и SkyAnA не умеют писать многопоточный код.

mikroncdtyjvНет, кэши не когерентны. Повторюсь - читайте про store buffer и invalidate queue.

Пакажи источник информации что кэши у х86 и х64 не когерентны. И может сможеш показать на примере?
И ненадо стигматизировать личности. Ошибки вобще свойственны людям.Давайте для начала будем употреблять термин "когерентны" правильно.
Утверждение "кэши не когерентны" не верно - они тогда бы просто напросто не работали.
Утверждение "кэши когерентны" не верно - они могут временно разъезжаться.
Правильнее всего сказать - "кэши eventually когерентны". Извиняюсь, не знаю более подходящего слова на русском. То есть они "когерентны со временем".

Теперь по ссылкам.
1. Идем в Гугл: https://www.google.ru/?q=intel developer manual
2. Оттуда на сайт Интела: http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
3. Жмем Ctrl-F, ищем по слову "memory".
4. Понимаем, что был некий вайтпапир про память, который смержили в главу 3A, открываем ее: http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf
5. Пробегаемся по оглавлению, замечаем главу 8.2 Memory Ordering, идем в нее.
6. Тут уж почитаете, что вам интересно. Например, 8.2.3.4 - это пример, который я приводил выше. А 8.2.3.5 - это ответ на ваш вопрос , как раз показывает, что когерентность может нарушаться.

mikron ,
Первая ссылка правильная. Вторая ссылка тоже была правильной ... в то время, когда публиковалась :-)

mikronК тому-же преведённый тобой документ тоже подтвержадет "Writes cannot move past other writes from the same thread."

"8.2.2 Memory Ordering in P6 and More Recent Processor Families"
-- Writes to memory are not reordered with other writes, with the following ...
-- Writes by a single processor are observed in the same order by all processors.Ну все верно, именно так x86 и работают (см. total store order).
Но в чем вопрос ваш заключается? Да, сторы не могут "заезжать" друг за друга на одном процессоре. Но это не гарантирует когерентности кэшей, что как раз и проиллюстрировано в примерах из спецификации Intel-овских процессоров, которые я вам приводил.

mikronИ вот человек говорит странное As it happens, Intel’s X86 and X64 processors always apply acquire-fences to reads and release-fences to writes — whether or not you use the volatile keyword — so this keyword has no effect on the hardware if you’re using these processors. Нет, это неверно. На самом деле, ситуация следующая. Давайте определим 4 типа "фенсов": LoadLoad, LoadStore, StoreLoad, StoreStore.
Например, "LoadStore" означает, что последующе сторы не могут быть поставлены до лоада, защищенного этим фенсом:


Семантика volatile выглядит вот так:



Но проблема в том, что в таком варианте int y0 = y может "заехать" за x = 1 в одном потоке, что приведет к вот этому: 16627718

Поэтому на самом деле волатильный стор выглядит вот так:



На x86 фенсы StoreStore, LoadLoad и LoadStore уже гарантированы архитектурой. А StoreLoad не гарантирован! Поэтому его имплементируют руками, например через "lock add(esp, 0)" или через какие-нибудь mfence.

Вывод: volatile работает не так, как обычные переменные даже на x86.

mikron"As it happens, Intel’s X86 and X64 processors always apply acquire-fences to reads and release-fences to writes — whether or not you use the volatile keyword". Автор говорит об общем случае (volatile or not it doesn't matter) а вы скатываетесь к часному (volatile).Вы фразу то целиком пишите. У нее там еще окончание есть, которое вы же и привели: "... so this keyword has no effect on the hardware if you’re using these processors."
Я вам и говорю - это неверно.

mikron2. Ваше утверждение, что "автор не прав" вызывает сомение. В вашем примере
для y0 есть сторе и значит по утвержденю автора acquire-fences. И следовательно не может быть переупорядочено. что вы собственно и доказываете. Но причина тому фенсе по утвержденю автора другая.Стора здесь нет. Вернее, может не быть: процессор может сохранить y0 в регистр, и работать там.
int y0 = y - это LOAD, а не STORE.

mikron4. И как вы считаете, какой ответе на вопрос: могут ли присваивания быть переупорядочены в терминах "CLR memory model"Не знаю. И не знаю, зачем мне это нужно.