Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Serginio1, Вы писали:
C>И охота тебе ветки плодить. Соберу все сюда.
S>> Вот процессор не будет запихивать данные в регистр только в области видимости кода. В другом методе уже скомпилирован код где поле закинуто в регистр и там прекрасно меняется.
S>>Как Interlocked.MemoryBarrier в другом методе может на это повлиять?
C>Хз, как оно работает с регистрами я не копал. Но Interlocked.MemoryBarrier делает синхронизацию памяти только для процессора текущего треда. Если нужно сделать это для всех процессоров, то для этого есть MemoryBarrierProcessWide, который работает намного медленнее. Для регистров там тоже что-то должно быть, иначе никакой многотредный код вообще бы не работал.
Там не синхронизация а упорядочивние инструкций
Барьер памяти
Барьер памяти (англ. memory barrier, membar, memory fence, fence instruction) — вид барьерной инструкции, которая приказывает компилятору (при генерации инструкций) и центральному процессору (при исполнении инструкций) устанавливать строгую последовательность между обращениями к памяти до и после барьера. Это означает, что все обращения к памяти перед барьером будут гарантированно выполнены до первого обращения к памяти после барьера.
S>>Это как? Конструктор это как раз гарантирует.
C>Приведи цитату, где написано что что-то в этом духе гарантируется для всех тредов, а не только для текущего.
А он создается только в одном потоке! Ты не можешь применить async к конструктору
S>> Это я с тебя охреневаю. Конструктр отдает ссылку после того как создан и заполен (инициализирован)объект
C>Сначала выделяется память и сохраняется ссылка на нее, потом заполняются поля объекта.
Угу ты хоть ссылки приводи на свои мысли!
А тебе уже приводили ссылку
http://rsdn.org/forum/dotnet/8203957.1Автор: xpalex
Дата: 23.02.22
Конструктор то как раз и создан для инициализации объекто до получения ссылки!
S>>Ссылка получается после выделения и заполнения памяти, но никак по другому. Если же ты заполняешь после конструктора без синхронизации то это уже твои проблемы!
C>Тебе известны какие-то спеки, которые говорят о таких гарантиях для всех тредов?
C>Мне известны спеки, которые говорят о прямо противоположном.
C>https://docs.microsoft.com/en-us/archive/msdn-magazine/2012/december/csharp-the-csharp-memory-model-in-theory-and-practice
C>C>One source of complexity in multithreaded programming is that the compiler and the hardware can subtly transform a program’s memory operations in ways that don’t affect the single-threaded behavior, but might affect the multithreaded behavior. Consider the following method:
C>XML
C>void Init() {
C> _data = 42;
C> _initialized = true;
C>}
C>If _data and _initialized are ordinary (that is, non-volatile) fields, the compiler and the processor are allowed to reorder the operations so that Init executes as if it were written like this:
C>XML
C>void Init() {
C> _initialized = true;
C> _data = 42;
C>}
C>The C# memory model permits reordering of memory operations in a method, as long as the behavior of single-threaded execution doesn’t change.
И где конструктор то? Ещер раз конструктор создается только в одном потоке и получает ссылку после инициализации конструктором.
S>>При создании объекта в конструкторе другие потоки его не читают ибо ссылки то нет. А вот если после создания какое то поле поместили в регистр, то вот здесь и надо предусмотреть эту ситуацию.
C>После создания объекта, нет никаких гарантий что другие треды получат и прочитают данные в том же порядке, как они были записаны. И даже что они были записаны в память в том же порядке, как ты написал в коде — тоже на самом деле не гарантируется.
А те бе не похрен в каком порядке инициализировна память? Она уже законнчена. Проблема с переупорядочиванием только когда одновременно пишем в одном потоке и читаем в друго.
При создании в конструкторе никакого чтения из другого потока не происходит! Если конечно не передать this в другой поток до полной инициализации. Но тут уж ты CCЗС
