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

AG>Вероятность того, что поток будет вытеснен, если внутри этого лока — только один вызов гетера/сетера — фактически нулевая.

Смысл в том, что она все равно не нулевая.
У нас в софте были такие зависания, оказалось там была схожая реализация лока с циклом на CMPXCHG.
Код под локом — всего несколько процессорных инструкций, но все равно иногда случалось, что
он вытеснялся и система висла (потому что за лок конкурировали другие важные потоки системы).
Когда переделали на стандартные виндовые spinlock/pushlock — все заработало.

AG>Каких-либо механизмов, способных разрулить проблему IMHO не существует.
AG>Кроме, разве что сделать ожидание в локе — с прокачкой сообщений ОС, и с вызовом Sleep...

Ну в ядре, как я уже писал, можно на время запретить переключение контекстов, ядерные
спинлоки так и работают (повышая IRQL до соответствующего уровня, где шедулер не работает).