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

Ф>>а завтра может быть пара из mov и cmp. Например потому, что это другой процессор, и там джиттер работает немного иначе.
MH>mov — всё равно из памяти будет читать
MH>то есть другого варианта нет
MH>дело не в том как джиттер работает. дело в том что при передаче управления в метод-геттера в теле метода надо читать филд, из памяти.

mov будет читать из памяти — других вариантов у него нет, но из ряда
mov -> cmp
mov -> cmp
mov -> cmp

можно исключить лишние мувы. Сам метод может быть заинлайнет, и тогда всё будет происходить не в get_IsDisposed, а в самом пользовательском методе, где как раз может быть поле для таких оптимизаций.


MH>

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

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

Проблема не в этом методе, а в том, что для этого поля оптимизации никто не запрещал.

MH>более того — если посмотреть в целом на ситуацию, то volatile не нужен. т.к. даже если мы гарантированно прочитали память, то в следующий момент ( может даже ещё до выхода из геттера) _disposed может оказаться выставленным,
MH>и вызывающая сторона ошибочно посчитает что ещё не диспозед, хотя уже диспозед. то есть volatile никак не предотвратит на 100% вызывающую Disposed сторону от ошибочного действия.

Угу, а потом ты будешь удивляться, что по логам пы коммит для транзакции послали, а транзакция куда-то пропала, хотя на самом деле никуда мы ничего не послали, а в этот момент сокет кто-то задиспозил.
Понимаешь, вовремя кинутое исключение ObjectDisposedException может тебе сократить неделю отладки.