Являются ли чтение / запись 64-битных значений атомарными на 64-битном процессоре?

Question

Являются ли чтение / запись 64-битных значений атомарными на 64-битном процессоре?

2

На 32-разрядных компьютерах чтение и запись 64-разрядных значений в .net раньше были неатомарными, т.е. при чтении я мог прочитать значение, которое никогда не записывалось в память, состоящее из одной более старой 32-разрядной половины, и одна новая половина.

Но являются ли операции чтения/записи атомарными на 64-битных процессорах?
Если да, то должна ли ОС (Windows) быть 64-битной?
И если да, то должно ли даже приложение быть 64-битной сборкой .net?

Eugene Beresovsky 24 окт. 2018, в 02:13

Источник

0

Я понятия не имею о 1, но могу сказать, что 2 и 3 обязательны. Вам нужно 64-битное приложение в 64-битной ОС в 64-битном процессоре
SO used to be good 23 окт. 2018, в 23:44
0

Код .NET Apps / MSIL по умолчанию не зависит от разрядности. Это означает, что тот же IL может выполняться как x32 или x64. И даже x128 и x16, если мы когда-нибудь получим runtiems для них. Но вам нужна операционная система x64 (которая требует аппаратного обеспечения x64) для выполнения программы x64. Обычно windows поддерживает «один шаг двоичной системы вниз». Как и в системах x32, все еще поддерживаются программы x16. И вы можете настроить программы IL на запуск только в определенных двоичных файлах в опциях сборки проекта / решения.
Christopher 23 окт. 2018, в 23:47
0

Я знаю только атомарность как свойство систем баз данных. И в этом контексте ничто в компьютерах не может быть гарантированно спасено от условий гонки, если вы не принудите это тоже. Или точно знаю, что это одна операция. Например, обратите внимание, что i++ - это просто сокращение для записи i=i+1 . Таким образом, это все еще операция чтения, а затем записи, а не одна операция чтения-записи.
Christopher 23 окт. 2018, в 23:50
0

@JohnB пожалуйста, не добавляйте бесполезные теги
SO used to be good 23 окт. 2018, в 23:53
1

@CamiloTerevinto Я перечитал тэг 32bit-64bit , потому что я считаю, что он действительно имеет отношение к этому вопросу.
Eugene Beresovsky 23 окт. 2018, в 23:55
2

определить useless ...
JohnB 23 окт. 2018, в 23:56
0

Для чего именно? Это не около 32 бит, а около 64 бит. Даже тег гласит «Проблемы, связанные с использованием 64-битной или 32-битной архитектуры», это совсем не так.
SO used to be good 23 окт. 2018, в 23:59
1

@Christopher: Вопрос не об атомарности в смысле базы данных, а скорее в смысле «развернутого чтения». Дело в том, что нам не нужно рассматривать сложные операции, такие как чтение-увеличение-запись, чтобы получить неожиданные результаты. Даже чтение в одном потоке и запись в другом может дать неожиданные результаты, если чтение и запись не являются атомарными.
Eric Lippert 24 окт. 2018, в 00:15
2

Я не уверен, почему этот вопрос получил внеочередное голосование. Хороший вопрос и интересный вопрос производительности, касающийся многопоточности ( UpVote ), также продолжение и соответствующий вопрос, заданный со вчерашнего дня. Самый быстрый способ безопасного чтения содержимого long, элементы которого изменяются одновременно
TheGeneral 24 окт. 2018, в 01:29

Показать ещё 7 комментариев

Теги:

c#

.net

atomic

32bit-64bit

1 ответ

Ещё вопросы

Я понятия не имею о 1, но могу сказать, что 2 и 3 обязательны. Вам нужно 64-битное приложение в 64-битной ОС в 64-битном процессоре
Код .NET Apps / MSIL по умолчанию не зависит от разрядности. Это означает, что тот же IL может выполняться как x32 или x64. И даже x128 и x16, если мы когда-нибудь получим runtiems для них. Но вам нужна операционная система x64 (которая требует аппаратного обеспечения x64) для выполнения программы x64. Обычно windows поддерживает «один шаг двоичной системы вниз». Как и в системах x32, все еще поддерживаются программы x16. И вы можете настроить программы IL на запуск только в определенных двоичных файлах в опциях сборки проекта / решения.
Я знаю только атомарность как свойство систем баз данных. И в этом контексте ничто в компьютерах не может быть гарантированно спасено от условий гонки, если вы не принудите это тоже. Или точно знаю, что это одна операция. Например, обратите внимание, что i++ - это просто сокращение для записи i=i+1 . Таким образом, это все еще операция чтения, а затем записи, а не одна операция чтения-записи.
@JohnB пожалуйста, не добавляйте бесполезные теги
@CamiloTerevinto Я перечитал тэг 32bit-64bit , потому что я считаю, что он действительно имеет отношение к этому вопросу.
Для чего именно? Это не около 32 бит, а около 64 бит. Даже тег гласит «Проблемы, связанные с использованием 64-битной или 32-битной архитектуры», это совсем не так.
@Christopher: Вопрос не об атомарности в смысле базы данных, а скорее в смысле «развернутого чтения». Дело в том, что нам не нужно рассматривать сложные операции, такие как чтение-увеличение-запись, чтобы получить неожиданные результаты. Даже чтение в одном потоке и запись в другом может дать неожиданные результаты, если чтение и запись не являются атомарными.
Я не уверен, почему этот вопрос получил внеочередное голосование. Хороший вопрос и интересный вопрос производительности, касающийся многопоточности ( UpVote ), также продолжение и соответствующий вопрос, заданный со вчерашнего дня. Самый быстрый способ безопасного чтения содержимого long, элементы которого изменяются одновременно

kristianp · Accepted Answer · 2018-10-23T21-38-00.000Z

Исходя из этого ответа, если вы работаете в 64-битной системе и используете 64-битную CLR, то они являются атомарными. Ответ ссылается на эту запись в блоге Эрика Липперта: https://blogs.msdn.microsoft.com/ericlippert/2011/05/31/atomicity-volatility-and-immutability-are-different-part-two/

Спецификация CLI фактически дает более сильные гарантии. CLI гарантирует, что чтение и запись переменных типов значений, которые имеют размер (или меньше) естественного размера указателя процессора, являются атомарными; если вы выполняете код С# в 64-битной операционной системе в 64-битной версии CLR, тогда чтение и запись 64-битных двойных и длинных целых также гарантированно будут атомарными. Язык С# не гарантирует этого, но спецификация времени выполнения дает. (Если вы выполняете код С# в какой-либо среде, которая не реализована какой-либо реализацией CLI, то, конечно, вы не можете полагаться на эту гарантию; обратитесь к поставщику, который продал вам среду выполнения, если вы хотите знать, какие гарантии они предоставляют.)

Обратите внимание, что чтение и запись должны быть выровнены. Процессору разрешается прерывать чтение, если, скажем, вы разыменовываете указатель на четырехбайтовую структуру, имеющую адрес с нечетным номером.
Я предполагаю, что running C# code [..] in a 64 bit version of the CLR исключит 32-битные сборки, работающие внутри 64-битной CLR (через WOW64).