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

AVK>>7) Хелпер, обеспечивающий использование ReaderWriterLock с оператором using.
N>Это, вроде отцы-основатели не рекомендуют делать. Они даже не рекмендуют больше lock использовать https://blogs.msdn.microsoft.com/ericlippert/2009/03/06/locks-and-exceptions-do-not-mix/

Описанная там проблема относится скорее в общем к exception safety guarantee, чем к различного рода lock'ам.

And of course, this is yet another reason why aborting a thread is pure evil. Try to never do so!

Я же говорил:

https://rsdn.ru/forum/philosophy/6063177.1

Автор: Evgeny.Panasyuk
Дата: 29.05.15

EP>>>Он может выкинуть исключение откуда угодно? Или только из обозначенных мест?
S>>Откуда угодно.

EP>Очень хрупкая концепция — получается что no-throw кода нет в принципе, что в некоторых случаях сильно затрудняет реализацию транзакционных операций.
EP>Надеюсь оно хоть не выкидывает новое исключение при повтором Thread.Abort в случае когда первое поймано или при выполнении finally/dispose?

(3) carefully implement the bodies of locks that do mutations so that in the event of an exception, the mutated resource is rolled back to a pristine state before the lock is released. (Good, but hard.)

При помощи scope(failure)/scope(success) это намногопроще.

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

AVK>>7) Хелпер, обеспечивающий использование ReaderWriterLock с оператором using.
N>Это, вроде отцы-основатели не рекомендуют делать. Они даже не рекмендуют больше lock использовать https://blogs.msdn.microsoft.com/ericlippert/2009/03/06/locks-and-exceptions-do-not-mix/

Описанная там проблема относится скорее в общем к exception safety guarantee, чем к различного рода lock'ам.

And of course, this is yet another reason why aborting a thread is pure evil. Try to never do so!

Я же говорил:

https://rsdn.ru/forum/philosophy/6063177.1

Автор: Evgeny.Panasyuk
Дата: 29.05.15

EP>>>Он может выкинуть исключение откуда угодно? Или только из обозначенных мест?
S>>Откуда угодно.

EP>Очень хрупкая концепция — получается что no-throw кода нет в принципе, что в некоторых случаях сильно затрудняет реализацию транзакционных операций.
EP>Надеюсь оно хоть не выкидывает новое исключение при повтором Thread.Abort в случае когда первое поймано или при выполнении finally/dispose?

(3) carefully implement the bodies of locks that do mutations so that in the event of an exception, the mutated resource is rolled back to a pristine state before the lock is released. (Good, but hard.)

При помощи scope(failure)/scope(success) это намного проще.