Безопасна ли установка копий из неизменяемых файлов от повреждения потока?

Запись ссылки в Java является атомарной (записи в longs или doubles только в том случае, если поле является volatile btw), но это само по себе не помогает.

Пример для демонстрации:

class Foo {
     int x;
     public Foo() { x = 5};
}

Предположим, что мы выполняем задание, например foo = new Foo() (без конечных или изменчивых модификаторов для foo!). С точки зрения низкого уровня это означает, что мы должны сделать следующее:

1. выделять память
2. запустите конструктор
3. назначьте адрес памяти в поле.

но до тех пор, пока конструктор не прочитает поле, которому мы его присваиваем, компилятор также может сделать следующее:

1. выделять память
2. назначьте адрес памяти в поле.
3. запустите конструктор

Резьбонарезной безопасно? Конечно, нет (и вы никогда не гарантируете, что увидите обновление, если не поместите барьеры памяти). Java дает больше гарантий, когда задействованы конечные поля, поэтому создание нового неизменяемого объекта будет потокобезопасным (вы никогда не увидите неинициализированное значение конечного поля). Неустойчивые поля (речь идет о присвоении здесь не полей в объекте), чтобы избежать этой проблемы и в java, и в С#. Не уверен, что С# и только для чтения.

В Java назначение ссылок и примитивов является атомарным, за исключением 64-битных примитивных типов long и double. Назначения Java long и double могут быть сделаны атомарными, объявив их с volatile модификатором. См.: 64-разрядные назначения в Java-атоме на 32-битной машине?

Это связано с тем, что спецификация Java VM требует его для того, чтобы виртуальная машина была совместимой с Java.

Scala работает поверх стандартной Java VM и поэтому также будет предоставлять те же гарантии, что и Java, в отношении присвоений, если они не начнут использовать JNI.

Одной из проблем с C/C++ (и одной из его сильных сторон) является то, что оба языка позволяют очень мелкозернизованное отображение структур данных на адреса памяти. На этом уровне, независимо от того, являются ли записи в память атомарными или не сильно зависят от аппаратной платформы. Например, CPU, как правило, не может считывать атомарно, не говоря уже о записи в переменные, которые не выровнены соответствующим образом. например, когда 16-битные переменные не совпадают с четными адресами или когда 32-битные переменные не выровнены по адресам, кратным 4, и так далее. Ухудшается, когда переменная выходит за пределы одной строки кэша в следующую или за одну страницу в другую. Следовательно, C не гарантирует, что присвоения будут атомарными.

В большинстве языков назначение объектов является атомарным.

В этом конкретном случае вам нужно быть осторожным, хотя, выполняя x=new X() на всех языках нет гарантии, что X полностью инициализируется до назначения. Я не уверен, где С# стоит на этом.

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

C++ определяет гонку данных в виде двух или более потоков, потенциально доступных одновременно для одного и того же места памяти, по меньшей мере одно из которых является модификацией. Поведение программ с расами данных не определено. Таким образом, нет, для нескольких потоков небезопасно обращаться к этому полю, если хотя бы один из них может его изменить.