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

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

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

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

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

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

Ф> Учитывай, что геттер Disposed вполне может быть заинлайнен.
это хороший аргумент. тут ты прав.
но опять, же проблема будет, если иналйниться внутри жирного метода в котором уже были вызовы Disposed, и да, тогда похоже jit сгенерить код, который воспользуется результатом пред чтения _disposed

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

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

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

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

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

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

Ф> Учитывай, что геттер Disposed вполне может быть заинлайнен.
это хороший аргумент. тут ты прав.
но опять, же проблема будет, если иналйниться внутри жирного метода в котором уже были вызовы Disposed, и да, тогда похоже jit может сгенерить код, который воспользуется результатом пред чтения _disposed