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

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

T>>В данном случае как раз поможет, и без всяких Interlocked-функций. InterlockedExchange — функция использующаяся
T>>для записи, а что ты предлагаешь использовать для чтения переменной, и тем более без volatile?
T>>Не вводи в заблуждение.

К>Чтобы прочитать, можно сделать такое
К>

К>value = InterlockedExchangeAdd(&var, 0);
К>value = InterlockedCompareExchange(&var, ANY_CONST, ANY_CONST);
К>

Обе функции требуют выравнивания по 32-битной границе, и что не дает никаких
преимуществ перед обычным чтением.

T>>InterlockedExchange генерирует memory barrier, который гарантирует последовательность выполнения операций
T>>с памятью, и в данном случае это не требуется.

К>Атомарно читаем расшаренные данные, и при этом пытаемся выцыганить немного времени на переупорядочивании?

Все же лучше чем атомарно читать + писать (как минимум в два раза быстрее).

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

__>>>

__>>>x ^= (y ^= (x ^= y));
__>>>

Q>>А это вообще Undefined Behavior.
U>пояснить можете, где тут UB ? какой пункт стандарта нарушается?
U>о каких типах переменных речь? int, unsigned ?

дык эта, модифицирование одной переменной несколько раз между точками следования.
бородатый пример.

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

NB>дык эта, модифицирование одной переменной несколько раз между точками следования.
NB>бородатый пример.
благодарю, что-то скобки меня с толку сбили
кстати, прикольный код, компилируемый в комо:

int a = a = a = a;

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

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

S>>так всетаки неясно насчет volatile...
S>>volatile в msdn
S>>в мсдн написано, что при каждой обращении будет считано текущее значение volatile переменной(из памяти имеется ввиду, да?). А далее говорится, что-то про Microsoft specific..там говорится о каких-то aquire и release semantics.. и что они означают я пока не понял... объясните кто-то пожалуйста)
S>>вот тут некая Алена С++ пишет, что это говорит о атомарности операций с переменной.
S>>Если это так... то это вроде то, что нужно.
S>>Вообще значение переменной меняется из одного потока, а вот считывается многими.. и если volatile действительно дает атомарность.. значит *Interlocked ф-ями можно не пользоваться. так?

T>Тут важно знать следующее:
T>* как уже было написано, атомарность чтения/записи в память на большинстве 32-бит, 64-битных архитектур(IA32, x64 в их числе) гарантируется,
T>если DWORD выровнен по 4-байтной сетке и выше. (это по умолчанию если не крутить соответствующие настройки проекта).
T>* volatile необходимо для того, что бы указать компилятору, что необходимо генерировать такой код, который
T>будет брать/записывать каждый раз значение из памяти, а не как иначе.

T>Тоесть тут два уровня: уровень компилятора(откомпилированного кода) и уровень процессора и памяти.

т.е. если я правильно понял — обойтись можно и без volatile? ведь если volatile говорит только о том, что переменная будет считана каждый раз из памяти — то какой в ней смысл, если она и так будет считана один раз в гетере..?
зы. класс — COM класс, компилятор ничего не заинлайнит.

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

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

S>>>интересно, а предыдущее значение устраивает?
S>>да. раз не успел... то ладно)

Q>На многопроцессорной системе может не успеть никогда (пока из локального кэша старое значение не вытеснится).
а можо в двух словах что такое локальный кеш? т.е. копия переменной в памяти хранится еще где-то, кроме памяти?

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

S>т.е. если я правильно понял — обойтись можно и без volatile? ведь если volatile говорит только о том, что переменная будет считана каждый раз из памяти — то какой в ней смысл, если она и так будет считана один раз в гетере..?
S>зы. класс — COM класс, компилятор ничего не заинлайнит.

Если COM, то можно обойтись.
Кроме прочего для понятности volatile можно использовать, что бы помечать,
что данная переменная или функция может быть безопасно использоваться
другими потоками.

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

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

S>>т.е. если я правильно понял — обойтись можно и без volatile? ведь если volatile говорит только о том, что переменная будет считана каждый раз из памяти — то какой в ней смысл, если она и так будет считана один раз в гетере..?
S>>зы. класс — COM класс, компилятор ничего не заинлайнит.

T>Если COM, то можно обойтись.
T>Кроме прочего для понятности volatile можно использовать, что бы помечать,
T>что данная переменная или функция может быть безопасно использоваться
T>другими потоками.

а в случае с 8-и байтовой переменнной? тоже можно использовать без volatile?

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

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

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

S>>>т.е. если я правильно понял — обойтись можно и без volatile? ведь если volatile говорит только о том, что переменная будет считана каждый раз из памяти — то какой в ней смысл, если она и так будет считана один раз в гетере..?
S>>>зы. класс — COM класс, компилятор ничего не заинлайнит.

T>>Если COM, то можно обойтись.
T>>Кроме прочего для понятности volatile можно использовать, что бы помечать,
T>>что данная переменная или функция может быть безопасно использоваться
T>>другими потоками.

S>а в случае с 8-и байтовой переменнной? тоже можно использовать без volatile?

Если 64-битный код, то да (необходимо выравнивание по 64 битам).

Если 32-битный:
Под XP и выше — использовать CriticalSection (выравнивание не требуется)

InterlockedExchange64 и InterlockedExchange64 то же требуют
выравнивания и работают начиная с Windows Server 2003 и Windows Vista.

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

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

S>>может ли быть, что доступ к этой переменной будет во время ее записи и, например, вернется не ее предыдущее(или новое) значение

S>а что в данном случае не воспользоваться interlocked функциями?
Воспользоватся можно хоть boost::через_*опу.
Вопрос был в том, какого решения достаточно для нормальной работы

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

T>Обе функции требуют выравнивания по 32-битной границе, и что не дает никаких преимуществ перед обычным чтением.

Вообще, выравнивание — вещь хорошая. Зачем в клиентском коде от него отступаться?
Тем более, когда мы гонимся за производительностью.

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

Q>>На многопроцессорной системе может не успеть никогда (пока из локального кэша старое значение не вытеснится).
S>а можо в двух словах что такое локальный кеш? т.е. копия переменной в памяти хранится еще где-то, кроме памяти?

Да, в дополительной быстрой памяти на самом процессоре. См. здесь