IA64 specifies a weaker memory model than X86. Specifically, all loads and stores are normal loads and stores. The application must use special ld.acq and st.rel instructions to achieve acquire and release semantics.
и тут же
In fact, the CLR has done exactly the same thing. Section 12.6 of Partition I of the ECMA CLI specification explains our memory model. This explains the alignment rules, byte ordering, the atomicity of loads and stores, volatile semantics, locking behavior, etc. According to that specification, an application must use volatile loads and volatile stores to achieve acquire and release semantics. Normal loads and stores can be freely reordered, as seen by other CPUs.
Я из этого сделал вывод, что JIT-компилятор для IA64 может гонерить код, выполняя
который IA64 процессоры будут писать в память в удобном им порадке.
Normal loads and stores can be freely reordered, as seen by other CPUs.
БП>Я из этого сделал вывод, что JIT-компилятор для IA64 может гонерить код, выполняя БП>который IA64 процессоры будут писать в память в удобном им порадке.
Хотелось бы расставить точки над i. Процессоры Itanium 2 никогда не выпоняют ни аппаратного реодеринга чтения и записи в память, ни вообще как-либо операций реордеринга. "The Itanium 2 processor hardware makes no attempt to reorder instructions to avoid stalls.". (На всякий случай отправляю к документу 25111002.pdf "Intel® Itanium® 2 Processor Reference Manual"). Все операции спекуляции выполняются только посредством программного кода (концепция EPIC). Поэтому, если и происходит какое-либо видимое со стороны другого процессора переупорядочивание чтение и записи, то только потому что такой код сгенерировал JIT: а именно "The family of instructions composed of ld.a/ldf.a/ldfp.a, ld.c/ldf.c/ldfp.c, and chk.a provide the capability to dynamically disambiguate memory addresses between loads and stores."
Здравствуйте, Блудов Павел, Вы писали:
БП>Нулевая. Ну-ле-ва-я. Об этом позаботится
поправь меня, если я ошибаюсь.
к моменту, когда завершится вот этот код:
public static Singleton Value
{
get
{
if (Singleton.value == null)
{
lock (syncRoot)
{
if (Singleton.value == null)
{
Singleton newVal = new Singleton();
// Insure all writes used to construct new value have been flushed.
System.Threading.Thread.MemoryBarrier();
Singleton.value = newVal; // publish the new value
}
}
}
return Singleton.value;
}
}
обновленное значение Singleton.value будет находиться в кэше процессора, в основную память оно будет сброшено позднее. В этот момент поток на другом процессоре может попытаться получить это значение, вызовется getter. Поскольку Singleton.value для него еще равен null, он создаст новый объект Singleton и запишет его в Singleton.value — в свою копию. (Поскольку на другом потоке геттер уже завершился, он вполне благополучно зайдет в lock).
И в результате мы получим две разные копии Singleton.
Здравствуйте, Блудов Павел, Вы писали:
БП>Здравствуйте, alexkro, Вы писали:
A>>У CLR есть своя модель памяти. На IA64 она не будет weak.
БП>Тогда я чего-то недопонял. Вот тут написано
БП>http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx
...
БП>Я из этого сделал вывод, что JIT-компилятор для IA64 может гонерить код, выполняя БП>который IA64 процессоры будут писать в память в удобном им порадке.
А после этого описывается реальная модель памяти майкрософтовской реализации CLR, которая гораздо более strong, чем спецификация ECMA CLI, а также предпологается, что следующия версия стандарта ECMA CLI будет следовать этой модели.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Блудов Павел, Вы писали:
БП>>Нулевая. Ну-ле-ва-я. Об этом позаботится
Д>поправь меня, если я ошибаюсь. Д>обновленное значение Singleton.value будет находиться в кэше процессора, в основную память оно будет сброшено позднее. В этот момент поток на другом процессоре может попытаться получить это значение, вызовется getter. Поскольку Singleton.value для него еще равен null,
lock(syncRoot) — это full fence. Все кэши в этом месте синхронизируются, и никаких read/write reordering не может произойти.
>он создаст новый объект Singleton и запишет его в Singleton.value — в свою копию. (Поскольку на другом потоке геттер уже завершился, он вполне благополучно зайдет в lock). Д>И в результате мы получим две разные копии Singleton.
Здравствуйте, alexkro, Вы писали:
A>lock(syncRoot) — это full fence. Все кэши в этом месте синхронизируются, и никаких read/write reordering не может произойти.
то есть он синхронизирует полностью всё содержимое всех кэшей?
Здравствуйте, alexkro, Вы писали:
A>lock(syncRoot) — это full fence. Все кэши в этом месте синхронизируются, и никаких read/write reordering не может произойти.
всё-таки не понял. А зачем тогда MemoryBarrier вызывать?
Здравствуйте, Дарней, Вы писали:
Д>всё-таки не понял. А зачем тогда MemoryBarrier вызывать?
Затем, что (читайте выше) Singleton.value может быть уже не null
и другой процессор уже может попытаться его исползовать. В этом
случае
lock(syncRoot)
НЕ ПРОИСХОДИТ. Так вот, для того, чтобы Singleton.value был отправлен
в память __последним__ а не каким-то, нужно и сбросить кеш.
Раньше это называли FlushProcessorCache. А теперь Memory barrier.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, alexkro, Вы писали:
A>>lock(syncRoot) — это full fence. Все кэши в этом месте синхронизируются, и никаких read/write reordering не может произойти.
Д>всё-таки не понял. А зачем тогда MemoryBarrier вызывать?
Это из другой оперы. Твоя логика была следующей:
1. Singleton.value == null -- true (Singleton.value in cache of another proc, not sync'd)
2. lock(syncRoot)
3. Singleton.value == null -- true (Singleton.value still in cache not sync'd)
Так вот, третье неверно. lock засинхронизирует кэш для данного потока (на данном процессоре) так, что Singleton.value получит текущее значение. Вообще, оно даже и на шаге 1 будет иметь текущее значение вследствие того, что запись в переменные, видимые глобально, является release, так же, как и запись в volatile переменные (а с volatile, как ты понимаешь, вообще всё без memory barrier работает).
Здравствуйте, alexkro, Вы писали:
A>А после этого описывается реальная модель памяти майкрософтовской реализации CLR, которая гораздо более strong, чем спецификация ECMA CLI
Это я читал. А в начале сказано, что вся эта дисскуссия всплыла из-за того, что на каком-то
32-головом IA64 при массивном стресс-тесте как раз и произошло что описано выше.
A>, а также предпологается, что следующия версия стандарта ECMA CLI будет следовать этой модели.
Это я тоже читал. Будем подождать. А то действительно получается что все конечно быстро
и круто, только программировать для таких процессоров должны не люди.
Павел.
Здравствуйте, Блудов Павел, Вы писали:
БП>Здравствуйте, Дарней, Вы писали:
Д>>всё-таки не понял. А зачем тогда MemoryBarrier вызывать?
БП>Затем, что (читайте выше) Singleton.value может быть уже не null БП>и другой процессор уже может попытаться его исползовать. В этом БП>случае
БП>lock(syncRoot)
БП>НЕ ПРОИСХОДИТ. Так вот, для того, чтобы Singleton.value был отправлен БП>в память __последним__ а не каким-то, нужно и сбросить кеш. БП>Раньше это называли FlushProcessorCache. А теперь Memory barrier.
Там даже еще похитрее будет. Memory barrier перед записью value не мешает другому потоку не увидеть данные, на которые указывает этот value. Как замечено в одном из комментариев http://blogs.msdn.com/brada/archive/2004/05/12/130935.aspx, там нужен ещё один memory barrier сразу после первого чтения Singleton.value. Тонкий момент. Многие не могут просечь (в том числе и я до конца, вероятно, не просекаю). В данном случае нужно полагаться на экспертов, которые этот вопрос разобрали и выяснили, как нужно делать правильно. Scott Meyers с этими экспертами помыкался с полгода и выдал резюме: http://www.nwcpp.org/Downloads/2004/DCLP_notes.pdf
Чем больше я об этом думаю, тем больше убеждаюсь,
что старую добрую двойную проверку настоятельно
будут рекомендовать к использованию в очень
исключительных случаях. Потому как два барьера
уже приводят фактически к lock(syncRoot) — разница
настолько мала, что овчинка перестает стоить
выделки.
МЮ>Хотелось бы расставить точки над i. Процессоры Itanium 2 никогда не выпоняют ни аппаратного реодеринга чтения и записи в память, ни вообще как-либо операций реордеринга. "The Itanium 2 processor hardware makes no attempt to reorder instructions to avoid stalls.". (На всякий случай отправляю к документу 25111002.pdf "Intel® Itanium® 2 Processor Reference Manual"). Все операции спекуляции выполняются только посредством программного кода (концепция EPIC).
В спецификации на Itanium (245317.pdf) memory access reodering идет полным ходом.В мане по Itanium2 (пунт 1.1) сказано, что он удовлетворяет специфицации Itanium architecture, за исключением явно указанных ограничений, среди которых идет упомяунтый instruction reodering.
Отказа от memory access reodering в 25111002.pdf я не видел. Напротив,пункт 6.7.5 из 25111002.pdf косвенно указывает
на присутствие реодеринга в Itanium2.
Здравствуйте, alexkro, Вы писали:
A>Так вот, третье неверно. lock засинхронизирует кэш для данного потока (на данном процессоре) так, что Singleton.value получит текущее значение.
всё-таки меня сомнения грызут. А где можно про это прочитать?
A>Вообще, оно даже и на шаге 1 будет иметь текущее значение вследствие того, что запись в переменные, видимые глобально, является release, так же, как и запись в volatile переменные (а с volatile, как ты понимаешь, вообще всё без memory barrier работает).
странно — в MSDN написано, что acquire/release поддерживается для volatile, а вот про static ничего такого не написано.
Блин, ничего толком понять не могу
И всё-таки, чем им вариант с volatile не понравился?
Здравствуйте, alexkro, Вы писали:
A>запись в переменные, видимые глобально, является release, так же, как и запись в volatile переменные (а с volatile, как ты понимаешь, вообще всё без memory barrier работает).
вот например тоже. про volatile написано, а про "просто" глобальные переменные — ни слова.
In
particular, however, the compiler will not move memory reads before a lock
aquire (or a volatile read), and will not move memory writes after a lock
release (or a volatile write), and will respect the MemoryBarrier APIs.
Здравствуйте, bw, Вы писали:
bw>В спецификации на Itanium (245317.pdf) memory access reodering идет полным ходом.В мане по Itanium2 (пунт 1.1) сказано, что он удовлетворяет специфицации Itanium architecture, за исключением явно указанных ограничений, среди которых идет упомяунтый instruction reodering.
bw>Отказа от memory access reodering в 25111002.pdf я не видел. Напротив,пункт 6.7.5 из 25111002.pdf косвенно указывает bw>на присутствие реодеринга в Itanium2.
Да, спасибо. Судя по всему реордеринг может происходить (245317.pdf, section 4.4.7), но не из-за динамического планировщика, которого нет, а из-за доступности данных на разных уровнях иерархии памяти.
