Атомарность присвоения

[7in]

У меня тут вопрос возник: будет ли обычное 32-битное присвоение (mov [X],eax), если переменная не выровнена по границе памяти, атомарным? Т.е. переменная 32-битная находится, скажем, по адресу 00FFFFFFh. Причём, прикол в том, что за-lock-ить её нельзя.

[Пепел Феникса]

не факт.
не спроста есть целое семейство Interlocked* функций.
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

[p51x]

Еще и от проца зависит...

[7in]

Пепел Феникса, функции InterlockedAssign нет. Более того, даже lock mov сделать нельзя! Не потому ли, что такая операция по любому атомарна. Или предполагается, что такие данные должны всегда быть выровнены?

p51x, вот тут хотелось бы поподробнее, плиз

[Пепел Феникса]

функции InterlockedAssign нет.

InterlockedExchange возьмите, вы можете игнорировать старое значение.
(потому Assign и нету)

Или предполагается, что такие данные должны всегда быть выровнены?

вообще да.

lock префикс он для read-modify-write инструкций.

[p51x]

Ну, например, у армов есть конвеер. И вполне возможна ситуация, что, если не аккуратно сделать, то mov положит переменную на конвеер, а другой поток будет читать из памяти другое значение.

[waleri]

Сообщение от p51x

Ну, например, у армов есть конвеер. И вполне возможна ситуация, что, если не аккуратно сделать, то mov положит переменную на конвеер, а другой поток будет читать из памяти другое значение.

К атомарности это отношения не имеет.
Даже без всякого конвейра вы можете прочитать "старые" данные.
"Атомарность" в данном контексте означает, что не получится ситуация, когда mov в одном потоке изменил часть переменной а в другом потоке mov прочитал ее. Гарантируется, что считывается либо старое значение, либо новое. Другое дело, при каких условиях это гарантируется - для х86 для этого требуется, чтоб данные были выровнены. Собственно, об этом прямым текстом написано в мануалах по InterlockedXXX вызовам.

[p51x]

Тогда причем тут lock из первого поста?

[Pavia]

Всё ниже моё гипотетическое, теоретическое предположение.
Нет не будет атомарной. Железо не обманешь. Оно вынуждено читать за 2 приема. А механизма защиты нет, по крайней мере интел пишет, что только выравненные на границе 4 байта. Хотя честно там так мутно это всё написано! майкрософт на 16 байт выравнивает мьютексы.

Более того, даже lock mov сделать нельзя!

Думаю что можно и он сработает. Но! Не на два участка памяти, а только на один. Поэтому для нас это бесполезно. Да и на разных машинах lock работает по разному.

Лично я для свой библиотеке сделал так. Мьютекс выравнен на границе 32 бит. В Delphi все 32 битные переменные так выровнены.
Для захвата использую.

lock  XCHG  DWord PTR [mutex],edx

А вот если хотите пропатчить код, то там данные не выровнены. Там либо использовать машинную команду cmpxchg8b (AtomicCompareExchange64) или медленный метод через средства ОС VirtualProtect(Addr, 5, PAGE_EXECUTE_READWRITE, OldProtect);.

[waleri]

Сообщение от p51x

Тогда причем тут lock из первого поста?

lock требуется для инструкций типа XCHG поскольку они выполняют и чтение и запись. Собственно lock можно выполнять с любой инструкцией, только смысла нет. lock посылает всем остальным процессорам сигнал "всем ждать, пока я закончу". Соотвественно lock инструкция блочится, пока остальные процы не скажут "мы ждем, о повелитель".