Synchronization actions, which are: * Volatile read. A volatile read of a variable.
* Volatile write. A volatile write of a variable.
* Lock. Locking a monitor
* Unlock. Unlocking a monitor.
* The (synthetic) first and last action of a thread
* Actions that start a thread or detect that a thread has
terminated, as described in §17.4.4.
Every execution has a synchronization order. A synchronization order is
a total order over all of the synchronization actions of an execution.
For each thread t, the synchronization order of the synchronization
actions (§17.4.2) in t is consistent with the program order (§17.4.3) of t.
И отсюда делаем вывод, что для volatile'ов запрещен reordering.
C> Synchronization actions, which are:
C> * Volatile read. A volatile read of a variable.
C> * Volatile write. A volatile write of a variable.
C> * Lock. Locking a monitor * Unlock. Unlocking a monitor.
C> * The (synthetic) first and last action of a thread *
C> Actions that start a thread or detect that a thread has
C> terminated, as described in §17.4.4.
C> Every execution has a synchronization order. A synchronization
C> order is a total order over all of the synchronization actions of
C> an execution.
C> For each thread t, the synchronization order of the
C> synchronization actions (§17.4.2) in t is consistent with the
C> program order (§17.4.3) of t.
C> И отсюда делаем вывод, что для volatile'ов запрещен reordering.
Вы вообще следите за дикуссией?
Сообщением выше я сказал что reorder разрешен для nonvolatile переменных.
Вы возразили. Теперь вы говорите: для volatile'ов запрещен reordering. Запрещен конечно. Только я этому и не возражал.
Yuri Khomich wrote: > C> И отсюда делаем вывод, что для volatile'ов запрещен reordering. > Вы вообще следите за дикуссией? > Сообщением выше я сказал что reorder разрешен для nonvolatile переменных. > Вы возразили.
Я не возражал. Я ответил, что лучше по-другому сформулировать — в новой
спеке добавилось запрещение на reorder для volatile.
Hello, Cyberax!
You wrote on Thu, 26 Oct 2006 12:50:32 GMT:
C>>> И отсюда делаем вывод, что для volatile'ов запрещен reordering. >> Вы вообще следите за дикуссией? >> Сообщением выше я сказал что reorder разрешен для nonvolatile >> переменных. >> Вы возразили. C> Я не возражал. Я ответил, что лучше по-другому сформулировать — в C> новой спеке добавилось запрещение на reorder для volatile.
Не подумайте, что я занимаюсь букво***ом , но вот ваши слова: "Скорее по-другому: для non-volatile переменных запретили reorder.". Это не так. Из-за чего и сыр-бор.
Или это описка просто?
Yuri Khomich wrote: > C> Я не возражал. Я ответил, что лучше по-другому сформулировать — в > C> новой спеке *добавилось* запрещение на reorder для volatile. > Не подумайте, что я занимаюсь букво***ом , но вот ваши слова: "Скорее > по-другому: для non-volatile переменных запретили reorder.". Это не так. > Из-за чего и сыр-бор. > Или это описка просто?
Действительно, очепятался. Очень извиняюсь.
Здравствуйте, Cyberax, Вы писали:
C>Потому что в спеке на CLR _явно_ прописано запрещение таких reorder'ов, C>гарантируется что память будет гарантировано когерентна. В спеке на JVM C>Memory Model такой гарантии не дается.
я правильно понимаю, что, как следствие, нельзя хранить переменные в регистрах и код вроде этого:
public class A {
public int count;
public static void main(String [] args) {
A a = new A();
for (int i = 0; i < 1000; i++) a.count++;
}
}
на .NET потенциально в разы медленнее т.к. нужно каждый раз count писать в память а то не дай бог соседний thread из него почитает?
n0name2 wrote: > я правильно понимаю, что, как следствие, нельзя хранить переменные в > регистрах и код вроде этого: > public class A { > public int count; > > public static void main(String [] args) { > A a = new A(); > for (int i = 0; i < 1000; i++) a.count++; > } > } > на .NET потенциально в разы медленнее т.к. нужно каждый раз count писать > в память а то не дай бог соседний thread из него почитает?
Не знаю, подозреваю что да. Хотя это достаточно редкая ситуация.
В .NET гарантируется, что поведение потока будет наблюдаться одинаково
из любого другого потока. В данном случае, в принципе, компилятор имеет
право вынести чтение и запись в a.count за пределы цикла, так как это не
меняет видимого поведения программы.
Здравствуйте, Cyberax, Вы писали:
C>Не знаю, подозреваю что да. Хотя это достаточно редкая ситуация.
почему, собственно, редкая? вообще сюда (потенциально) относится любое присваивание или модификация любых полей или ссылок. т.е. фактически любое изменение состояния.
C>В .NET гарантируется, что поведение потока будет наблюдаться одинаково C>из любого другого потока. В данном случае, в принципе, компилятор имеет C>право вынести чтение и запись в a.count за пределы цикла, так как это не C>меняет видимого поведения программы.
почему не меняет? допустим, этот main() запущен в двух потоках над одним и темже экземпляром A.
тогда вроде как нужно заново читать a.count перед каждой операцией ++ и каждый раз записывать a.count в память чтобы результаты были доступны всем?
причем по сути VM не знает — может ли данная переменная быть использована в нескольких протоках (нет escape analysis) и должна по умолчанию делать все переменные аналогом Java volatile?
