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

MH>Здравствуйте, Философ, Вы писали:

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

Ф>>>>volatile запрещает оптимизации компилятора в отношении поля. В ином случае Disposed может вернуть false там, где должен быть true, потому что false может "застрять" в регистре, куда ранее была зачитана ячейка памяти.
MH>>>

MH>>>internal bool Disposed => _disposed != 0;
MH>>>

MH>>>когда будет вызван гетер для Disposed — вариантов кроме как прочитать _disposed из памяти нет. не будет он из регистра читаться

Ф>>Такие гарантии может дать только volatile, т.е. запрет оптимизаций.
MH>нет. нет других вариантов для реализации этого метода кроме как генерировать ассемблерную инструкцию чтения памяти.

Есть другие варианты. Сегодня генерируется
cmp byte ptr [rcx+8],0; в RCX указатель this
а завтра может быть пара из mov и cmp. Например потому, что это другой процессор, и там джиттер работает немного иначе.

MH>volatile — актуальна, когда в рамках одного метода надо запретить компилятору оптимизации. вот в таком кейсе (в жирном методе с рядом обращений к филду) он вполне может после 1-го чтения, запомнить результат в регистре
MH>и затем к нему обращаться.

Проблема как раз в том, что метод вполне себе может быть жирным, и ты это никак не можешь проконтролировать. Просто очередной программист напишет пяток Receive() и пару Send() — всё, приехали: вот он простор для компиляторных оптимизаций.

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

MH>>>когда будет вызван гетер для Disposed — вариантов кроме как прочитать _disposed из памяти нет. не будет он из регистра читаться

Ф>>Такие гарантии может дать только volatile, т.е. запрет оптимизаций.
MH>нет. нет других вариантов для реализации этого метода кроме как генерировать ассемблерную инструкцию чтения памяти.

Есть другие варианты. Сегодня генерируется
cmp byte ptr [rcx+8],0; в RCX указатель this
а завтра может быть пара из mov и cmp. Например потому, что это другой процессор, и там джиттер работает немного иначе. И очередной mov вполне может быть опущен.

MH>volatile — актуальна, когда в рамках одного метода надо запретить компилятору оптимизации. вот в таком кейсе (в жирном методе с рядом обращений к филду) он вполне может после 1-го чтения, запомнить результат в регистре
MH>и затем к нему обращаться.

Проблема как раз в том, что метод вполне себе может быть жирным, и ты это никак не можешь проконтролировать. Просто очередной программист напишет пяток Receive() и пару Send() — всё, приехали: вот он простор для компиляторных оптимизаций.