Здравствуйте, MaximE, Вы писали:
ME> Хотелось бы увидеть кусок кода, который испрользует Interlocked* ф-ции для изменения глобальной переменной, разделяемой между потоками, и который не работал бы если переменная не volatile.
ME>[/list]
Отчего ты так уперся в Interlocked*?
Из чего следует, что оба параллельных потока непременно будут изменять переменную? Один поток может изменять, а другой — только опрашивать. Можно, конечно, извратиться посредством InterlockedExchangeAdd с нулем, но это будет именно ненужное извращение.
Когда оба потока используют Interlocked* в отношении одной переменной — разумеется, компилятор не знает, что функция будет делать с переданной переменной, и всяко сгенерит повторное чтение. Если для организации барьера используется целевой примитив, которому передается ссылка на объект — будет то же самое.
А вот в ядре виндов барьер делает функция KeMemoryBarrier без параметров — откуда компилятор после ее вызова узнает, что значение не-volatile переменной могло измениться? Потом, если производится обширная работа с множеством объектов внутри критической секции — откуда компилятору узнать, что внутри секции нужно заново перечитывать данные из памяти? Это ему сообщит либо volatile, либо запрет глубокой оптимизации.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
