tripol wrote:

> Интересно как, ведь операции процессора являются дискретными, а в данном
> случае я полагаю
> используется 32-битный код, следовательно чтение или запись производится
> одной

Кто тебе сказал, что операции процессора являются дискретными ?

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

MZ>tripol wrote:

>> Интересно как, ведь операции процессора являются дискретными, а в данном
>> случае я полагаю
>> используется 32-битный код, следовательно чтение или запись производится
>> одной

MZ>Кто тебе сказал, что операции процессора являются дискретными ?

А что, по твоему, процессор записывает в память / кэш по половине DWORD?

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

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

S>>Какой угодно, где стоит винда)

AL>Тогда никаких расслоений значения при чтении/записи из разных нитей не будет, можно не бояться.

Неправда Ваша. На старых процах случалось, потому interlocked-функции и появились. И никакой гарантии, что на будущих проблема опять не выплывет.

__>Неправда Ваша. На старых процах случалось, потому interlocked-функции и появились. И никакой гарантии, что на будущих проблема опять не выплывет.

Гарантия есть — обратная совместимость.

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

__>Неправда Ваша. На старых процах случалось, потому interlocked-функции и появились. И никакой гарантии, что на будущих проблема опять не выплывет.

На каких именно процах, где может функционировать Windows, команда пересылки между 32-разрядным регистром и памятью не была атомарной?

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

__>Неправда Ваша. На старых процах случалось, потому interlocked-функции и появились. И никакой гарантии, что на будущих проблема опять не выплывет.

interlocked-инструкции и функции появились для реализации высокоуровневых атомарных операций, которые нельзя реализовать одной существующей инструкцией (например, CAS, инкремент и пр.).

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

S>Спасибо. Я так понимаю, Критические секции и мьютексы работают медленнее, чем Interlocked ф-ии?

Мьютексы — однозначно медленнее. Критические секции — как повезет, но однозначно не быстрее. Ну и основное и единственное назначение Interlocked-функций — обеспечивать атомарность операции доступа. Не стоит еще какой-нибудь велосипед изобретать.

S>И еще. тут предложили использовать volatile.. поможет ли volatile? компилятор — vs2005.

В данном случае — ничем, как и остальные средства языка. В следующем стандарте обещают ситуацию исправить.

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

AL>На каких именно процах, где может функционировать Windows, команда пересылки между 32-разрядным регистром и памятью не была атомарной?

Сам лично сталкивался на двухпроцессорной четверке. Зависит, кстати, не столько от процессора, сколько от контроллера кеша.

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

AL>interlocked-инструкции и функции появились для реализации высокоуровневых атомарных операций, которые нельзя реализовать одной существующей инструкцией (например, CAS, инкремент и пр.).

И эта тоже?

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

S>>И еще. тут предложили использовать volatile.. поможет ли volatile? компилятор — vs2005.

__>В данном случае — ничем, как и остальные средства языка. В следующем стандарте обещают ситуацию исправить.

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

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

Ну тоесть InterlockedExchange — функция использующаяся и для чтения, но volatile необходимо,
кстати оно присутствует в объявлении функции
LONG __cdecl InterlockedExchange(
__in_out LONG volatile* Target,
__in LONG Value
);

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

__>Здравствуйте, A.Lokotkov, Вы писали:

AL>>interlocked-инструкции и функции появились для реализации высокоуровневых атомарных операций, которые нельзя реализовать одной существующей инструкцией (например, CAS, инкремент и пр.).

__>И эта тоже?

Ну насколько я знаю команды процессора такой нет.

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

__>Здравствуйте, A.Lokotkov, Вы писали:

AL>>interlocked-инструкции и функции появились для реализации высокоуровневых атомарных операций, которые нельзя реализовать одной существующей инструкцией (например, CAS, инкремент и пр.).

__>И эта тоже?

Конечно да, поскольку невозможно объяснить компилятору языка высокого уровня, что программист желает атомарно обменять содержимое двух ячеек памяти либо вернуть старое значение, заменив его на константу.

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

__>>И эта тоже?

T>Ну насколько я знаю команды процессора такой нет.

Атомарно вернуть старое значение, заменив его константой, на x86 можно при помощи древней xchg.

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

T>Вполне может прооптимизировать такой код:


T>

T>    while(!a.get_a()) // здесь может заинлайнить и без volatile цикл не выйдет
T>

Согласен, хотя к проблеме, поднятой топикстартером, это мало относится. И, кстати, InterlockedExchange заодно уж и эту опасность устранит.

T>И вообще рекомендуется применять volatile для таких случаев всегда независимо от того,
T>заоптимизирует данный компилятор или нет.

Ну, это смотря что считать "таким случаем". Можно и производительность нафиг загробить. Если в общем рассуждать, лучше доступ ко всему объекту из разных потоков грамотно организовывать, а не на уровне отдельных членов.

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

AL>Конечно да, поскольку невозможно объяснить компилятору языка высокого уровня, что программист желает атомарно обменять содержимое двух ячеек памяти либо вернуть старое значение, заменив его на константу.

x ^= (y ^= (x ^= y));

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

T>Ну тоесть InterlockedExchange — функция использующаяся и для чтения, но volatile необходимо,
T>кстати оно присутствует в объявлении функции
T>LONG __cdecl InterlockedExchange(
T> __in_out LONG volatile* Target,
T> __in LONG Value
T>);

Вот теперь согласен

__>Согласен, хотя к проблеме, поднятой топикстартером, это мало относится. И, кстати, InterlockedExchange заодно уж и эту опасность устранит.

Не вижу смысла каждый раз читать + писать в память тогда когда достаточно просто читать или просто писать.

T>>И вообще рекомендуется применять volatile для таких случаев всегда независимо от того,
T>>заоптимизирует данный компилятор или нет.

__>Ну, это смотря что считать "таким случаем". Можно и производительность нафиг загробить. Если в общем рассуждать, лучше доступ ко всему объекту из разных потоков грамотно организовывать, а не на уровне отдельных членов.

Производительность как раз можно загробить там где без необходимости используются memory barriers и лишние
записи / чтения.

А спецификатор volatile исключает вышеприведенную зацикленность и другие подобные возможные случаи.

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

__>

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

Здесь будет сгенерировано около шести пересылок между памятью и регистрами. Про то, что все это должно произойти атомарно, здесь не написано.

tripol wrote:

> А что, по твоему, процессор записывает в память / кэш по половине DWORD?

С уверенностью можно сказать только одно: меньше чем байт в память не
записать и не считать из неё. А вот остальное ...