Информация об изменениях

Сообщение Re[6]: Проект утилитной библиотечки от 17.03.2016 20:59

Изменено 17.03.2016 21:08 nigh

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

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


N>>Да нет, там все гораздо глубже. Основная мысль в том, что Disposable и try-finally для семантики локов не подходят и создают ложное ощущение безопасности.


EP>Это проблема exception safety guarantees, она существует и без всяких локов или даже потоков. Она даже существует без using'ов, только ещё хуже.

EP>А вот RAII, Using'и, try-with-resourcues как раз подходят к семантике локов, а ложное ощущение безопасности — это от незнания exception safety.
Я с этим не спорю. Просто когда вы пишете библиотчный код надо думать о самых глупых пользователях и не подталкивать их писать потенциально проблемный код, давая для этого удобные инструменты.

N>>
N>>WithdrawMoney(AccountB, 100)    //throw an exception here, will never unlock unless proper recovery is done - likely a deadlock, but not further data corruption by other threads
N>>


EP>Если тебе нравиться "likely a deadlock, but not further data corruption by other threads" — то лучше сразу на первом же исключении пристреливать программу и тормозить всю систему

Мне оно не особо нравится, просто в ряде задач это лучше, чем data corruption. Более того, правильную обработку exceptionа во втором случае можно где-нибудь ниже по стеку сделать, в отличие от.
Пристреливать всю программу необязательно (хотя можно), есть, скажем таймауты — другие треды будут продолжать нормально работать.
Re[6]: Проект утилитной библиотечки
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


N>>Да нет, там все гораздо глубже. Основная мысль в том, что Disposable и try-finally для семантики локов не подходят и создают ложное ощущение безопасности.


EP>Это проблема exception safety guarantees, она существует и без всяких локов или даже потоков. Она даже существует без using'ов, только ещё хуже.

EP>А вот RAII, Using'и, try-with-resourcues как раз подходят к семантике локов, а ложное ощущение безопасности — это от незнания exception safety.
В C# средствами языка exception safety не достигается. Даже checked exceptions нету (от них больше вреда чем пользы). Мы же тут C# обсуждаем?

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

N>>
N>>WithdrawMoney(AccountB, 100)    //throw an exception here, will never unlock unless proper recovery is done - likely a deadlock, but not further data corruption by other threads
N>>


EP>Если тебе нравиться "likely a deadlock, but not further data corruption by other threads" — то лучше сразу на первом же исключении пристреливать программу и тормозить всю систему

Мне оно не особо нравится, просто в ряде задач это лучше, чем data corruption. Более того, правильную обработку exceptionа во втором случае можно где-нибудь ниже по стеку сделать, в отличие от.
Пристреливать всю программу необязательно (хотя можно), есть, скажем таймауты — другие треды будут продолжать нормально работать.