Здравствуйте, B0FEE664, Вы писали:
L>Скажу резко — если вы в своем коде ожидаете дедлок, то вам лучше не заниматься многопоточным программированием. По крайней мере пока. L>>Серьезнее некуда. BFE>Вы в самом деле считаете переход на личность серьёзным аргументом?
А где ты увидел преход на личности? Это опыт. Ничего личного.
L>>Видимо, придется плакать. L>>Обнаруживать дедлок в момент исполнения уже поздно. Как в моем примере с однопутной железной дорогой. BFE>Вы такой эмоциональный.
Исправь дедлок на однопутной железной дороге после обнаружения. Потом рассуждай об эмоциях.
L>>А если это не данные, а команда на открытие воздушного прервыателя на 300 КВ, у которого trip time под десять секунд и наработка на отказ всего несколько десятков переключений и при попытке получить его текущий статус твой тред залип? Ты хочешь послать команду на закрытие, чтобы "восстановиться и попробовать снова"? Боюсь, тебе даже не дадут забрать свои вещи из кьюбилка, если ты такое предложишь, потому что этот факап может стоить кому-то жизней, а компании — многомиллионных судебных исков. BFE>Вы всё время ссылаетесь на runtime системы. Скажите, а в своих runtime системах вы работаете в терминах ниток обменивающихся данными или, всё же, в терминах real-time таймеров?
Мы работаем в терминах архитектурных решений, разработанных специально для конкретных нужд. Будут это потоки, таймеры или даже вовсе прерывания от устройств, нам совершенно неважно.
И ты с темы не соскакивай. Расскажи, как ты будешь исправлять такой дедлок.
L>>Дедлок в общем случае — не восстанавливаемая ситуация. Period. L>>Факт дедлока говорит о серьезном факапе в execution flow и рассчитывать на то, что тебе удастся откатиться, нельзя. BFE>В общем случае, если вы пишите на C++ и не можете безопасно развернуть стек, то вы пишите с ошибками. Или у вас вокруг каждого вызова функции стоит try-catch ?
Еще раз. Ты можешь хоть десять раз развернуть стек, и можешь даже вприсядку сплясать при этом. Но, даже в простом случае для того, чтобы откатиться и "попробовать снова", тебе нужно в первую очередь убрать причину дедлока. Удачи в этом, как говорится, и удачи не поймать еще один deadlock exception где-нибудь при "откате и повторе". Но в общем случае даже в системе без внешних исполнительных устройств, откатиться назад ты не сможешь — другие потоки-то работали и данные, с которыми твой поток поймал лок, как правило, после отката уже устарели. Ну а если есть исполнительные устройства — смотри выше.
L>>Еще раз — исправлять косяки проектирования в рантайме поздно. И в общем случае невозможно. BFE>В самом деле, если у вас все данные протаскиваются через одну нитку, то исправить такой архитектурный косяк при нехватки производительности невозможно.
Никому не интересна высокая производительность системы, которая не может работать корректно. Сегодня любому самоделкину доступны технологии, с которыми он в гараже может построить машину, развивающую более 300 км/ч на прямой. Одна загвоздка — Нюрбургринг почему-то выгрывают далеко не самые быстрые машины.
С другой стороны, корректно и стабильно работающую систему, да еще и покрытую серией автотестов, весь косяк которой своидтся к недостаточной производительности, всегда можно смасштабировать. Особенно если ее разработчики такую возможность предусмотрели.
И, чтобы уж добить. У нас есть система, в которой все данные "протаскиваются через одну нитку". Пока что ни один другой продукт на рынке не смог добиться даже 1/1000 от ее производительности и 1/100 от масштабируемости. Угадай, почему?
Здравствуйте, B0FEE664, Вы писали:
L>>>>Дедлок — по определению непредусмотренное поведение программы. BFE>>>Не более, чем исключение. EP>>Всё же deadlock (незапланированный) это ошибка в коде программы — то есть не исключение, а скорее assert. BFE>Нет, это не ошибка, если такое поведение ускоряет выполнение приложения и было предусмотрено заранее.
Нет. Это ошибка. Без исключений. Вдвойне ошибка — оправдывать это ускорением. Причем "ускорение" это весьма умозрительное.
Здравствуйте, B0FEE664, Вы писали:
BFE>Может и не лучший, но вот, что поиском нашёл в стандарте:
Стандарт не описывает, как именно детектится дедлок, кроме случая, когда один и тот же поток пытается дважды забрать нерекурсивный мьютекс. Как и зачем это попало в стандарт —
BFE>Так что если пользоваться стандартом, то такие исключения надо обрабатывать.
Единственный правильный способ обработать такое исключение — записать дамп и упасть.
Здравствуйте, Lazin, Вы писали:
L>>Зачем ты ее поломал?
L>Я ничего не делал, она сама просто взяла и загорелась
Ого.
Наверное, дедлок где-то в проводке
L>Ты меня тогда не понял, видимо. Я в курсе что нужно делать хорошую архитектуру, в которой невозможны дедлоки и не делать плохую. Дело в том, что я прячу отдельные мьютексы за интерфейсом и говорю что объекты можно лочить так и так. Пользователь может решить (ошибочно), что он лочит разные объекты и дедлок невозможен в принципе, даже если он это делает в разном порядке, так как объекты реально разные и его архитектура это гарантирует, это и было бы так, если бы он использовал мьютексы напрямую, но у меня может получиться конфликт и возникнет дедлок. Поинт в том, что если ты берешь на себя захват/освобождение мьютексов а также сам мапишь их на разные объекты программы — ты также должен предоставить механизм проверки корректности. Period. Нормальная библиотека должна учитывать разные аспекты ее использования, не только основную логику и производительность, но и тестируемость, отлаживаемость и человеко-понимаемость.
Ой. Все, что от нормальной библиотеки требуется — это четкая гарантия thread safety. Должно быть четко документировано, какие методы безусловно безопасны, какие — безопасны при условии того, что они работают с разными данными, а какие требуют блокировки. Еще необходимо четко описать, как именно и из какого потока вызываеются колбеки.
Как пользователь 100500 разных библиотек, насмотревшийся всякго, попрошу — пожалайста, не надо делать ничего больше! Для библиотеки крайне важно не совершать никаких ненаблюдаемых извне и не запрошенных явно действий.
L>>Они как минимум убирают необходимость в 100500 явных блокировок. L>atomic-и это тоже синхронизация
В идеале atomic это просто объект данных, который гарантированно можно целиком записать за одну операцию и при этом у него не будет внешне наблюдаемого промежуточного "недозаписанного" состояния.
L>>Ты кагбы можешь мне это не рассказывать, для меня IEC61850, MODBUS, BACNET, DNP3 и прочие страшные слова — вовсе не пустой звук. Но мы подобных проблем почему-то не имеем. L>софт о котором я говорил не имеет подобных проблем, просто приведен в качестве примера сервиса, обрабатывающего столько данных, сколько по твоему не бывает он используется, например, в ЦДУ СО ЕЭС (судя по использованным аббревиатурам ты должен знать что это такое) для сбора всей телеметрии, какая только есть
Эээ, это тебе в СО ЕЭС показалось, что там много данных? А я-то уж было напрягся
Здравствуйте, Evgeny.Panasyuk, Вы писали:
BFE>>Так что если пользоваться стандартом, то такие исключения надо обрабатывать.
Microsoft'ы, кстати, кидают на рекурсивных локах (VS13):
std::mutex m;
try {
m.lock();
m.lock();
}
catch(std::exception& e) {
std::cout << "exception: " << e.what() << std::endl;
}
> device or resource busy : device or resource busy
EP>Во-первых, какие-то специальные телодвижения не нужны (разве что поставить assert ) — там же в корне std::exception. EP>Во-вторых, опять-таки — это же явный баг в программе, если уж случилось такое, то неизвестно как там оно дальше пойдёт в разнос.
Можно попробовать остановиться... Исключение предотвращает сам deadlock, мьютекс в корректном состоянии остается, так что корректная остановка потенциально вполне возможна.
Понятно что баг и использовать нельзя, но может можно на стабильную предыдущую версию откатиться или ещё что.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Можно конечно представить некий fault tolerance, который закладывается и на такие баги кода, но имхо кидать исключение в таком случае всё равно не лучший вариант. BFE>>Может и не лучший, но вот, что поиском нашёл в стандарте: BFE>>
BFE>>3 Throws: Any exception thrown by pm->lock(). system_error if an exception is required (30.2.2).
BFE>>system_error with an error condition of operation_not_permitted if pm is 0. system_error with
BFE>>an error condition of resource_deadlock_would_occur if on entry owns is true.
BFE>>
EP>Видел это. Какой именно была rationale — не знаю, возможно максимальная гибкость.
Я тоже не читал логического обоснования этого, но идея кажется здравой.
BFE>>Так что если пользоваться стандартом, то такие исключения надо обрабатывать. EP>Во-первых, какие-то специальные телодвижения не нужны (разве что поставить assert ) — там же в корне std::exception.
assert — это исключительно средство разработки. В дебаг версии на него можно вообще никогда не наткнуться.
EP>Во-вторых, опять-таки — это же явный баг в программе, если уж случилось такое, то неизвестно как там оно дальше пойдёт в разнос.
Скажите, а вот когда происходит exception не связанный с отказом оборудования, это ошибка в программе или нет?
Здравствуйте, landerhigh, Вы писали:
L>А где ты увидел преход на личности? Это опыт. Ничего личного.
Согласно моему опыту, качество архитектурных решений следует выбирать с учётом квалификации членов команды. Архитектурное решение выбранное в команде говорит об уровне квалификации членов этой команды.
L>>>Видимо, придется плакать. L>>>Обнаруживать дедлок в момент исполнения уже поздно. Как в моем примере с однопутной железной дорогой. BFE>>Вы такой эмоциональный. L>Исправь дедлок на однопутной железной дороге после обнаружения. Потом рассуждай об эмоциях.
Вы разговариваете сами с собой. Какая ещё однопутная железная дорога? Давайте без демагогических аналогий.
BFE>>Вы всё время ссылаетесь на runtime системы. Скажите, а в своих runtime системах вы работаете в терминах ниток обменивающихся данными или, всё же, в терминах real-time таймеров? L>Мы работаем в терминах архитектурных решений, разработанных специально для конкретных нужд. Будут это потоки, таймеры или даже вовсе прерывания от устройств, нам совершенно неважно.
Ясно.
L>И ты с темы не соскакивай. Расскажи, как ты будешь исправлять такой дедлок.
deadlock в реалтайм системе с необратимыми действиями? Очевидно, что один из локов лишний. Оба действия должны лежать быть защищены одним синхронизирующим объектом. А как это относится к теме?
L>>>Дедлок в общем случае — не восстанавливаемая ситуация. Period. L>>>Факт дедлока говорит о серьезном факапе в execution flow и рассчитывать на то, что тебе удастся откатиться, нельзя. BFE>>В общем случае, если вы пишите на C++ и не можете безопасно развернуть стек, то вы пишите с ошибками. Или у вас вокруг каждого вызова функции стоит try-catch ?
L>Еще раз. Ты можешь хоть десять раз развернуть стек, и можешь даже вприсядку сплясать при этом. Но, даже в простом случае для того, чтобы откатиться и "попробовать снова", тебе нужно в первую очередь убрать причину дедлока. Удачи в этом, как говорится, и удачи не поймать еще один deadlock exception где-нибудь при "откате и повторе". Но в общем случае даже в системе без внешних исполнительных устройств, откатиться назад ты не сможешь — другие потоки-то работали и данные, с которыми твой поток поймал лок, как правило, после отката уже устарели. Ну а если есть исполнительные устройства — смотри выше.
Так или иначе, но исключение произойти может. Значит вам в любом случае, хотите вы этого или нет, придётся, хоть с бубном, хоть с плясками, но откатывать стек до какого-то уровня. И умение обрабатывать ошибочные ситуации определяет ваше умение писать качественный софт. Всех возможных ситуаций вы в сложном проекте предусмотреть заранее не сможете, так что если ваша архитектура не включает в себя обработку ошибочных ситуаций, значит у вас получится некачественный продукт, который работает только в тепличных условиях.
L>>>Еще раз — исправлять косяки проектирования в рантайме поздно. И в общем случае невозможно. BFE>>В самом деле, если у вас все данные протаскиваются через одну нитку, то исправить такой архитектурный косяк при нехватки производительности невозможно. L>Никому не интересна высокая производительность системы, которая не может работать корректно.
А я разве с этим спорю?
L>С другой стороны, корректно и стабильно работающую систему, да еще и покрытую серией автотестов, весь косяк которой своидтся к недостаточной производительности, всегда можно смасштабировать. Особенно если ее разработчики такую возможность предусмотрели.
О, да! Знаю я эти сказки.
L>И, чтобы уж добить. У нас есть система, в которой все данные "протаскиваются через одну нитку". Пока что ни один другой продукт на рынке не смог добиться даже 1/1000 от ее производительности и 1/100 от масштабируемости. Угадай, почему?
Это интересная игра: угадай почему чёрный ящик делающий неведомо что, работает лучше, чем другой чёрный ящик.
Попробую угадать.
Количество инсталляций системы меньше сотни?
Программа раздаётся бесплатно?
Замедление в 1000 пользователь всё равно заметить не сможет?
Здравствуйте, landerhigh, Вы писали:
BFE>>Может и не лучший, но вот, что поиском нашёл в стандарте: L>Стандарт не описывает, как именно детектится дедлок, кроме случая, когда один и тот же поток пытается дважды забрать нерекурсивный мьютекс. Как и зачем это попало в стандарт —
Раз стандарт не описывает, как именно происходит обнаружение deadlock'а, то это значит, что в общем случае вы не можете предполагать, что он не детектируется.
BFE>>Так что если пользоваться стандартом, то такие исключения надо обрабатывать. L>Единственный правильный способ обработать такое исключение — записать дамп и упасть.
Упасть — не вариант. (У вас что, поддержка платная?)
4 [ Note: A program may deadlock if the thread that owns a mutex object calls lock() on that object. If
the implementation can detect the deadlock, a resource_deadlock_would_occur error condition may be
observed. —end note ]
Здравствуйте, B0FEE664, Вы писали:
BFE>Раз стандарт не описывает, как именно происходит обнаружение deadlock'а, то это значит, что в общем случае вы не можете предполагать, что он не детектируется.
Я предпочитаю знать, что он не возникает, а не надеяться на чьи-то предположения.
BFE>>>Так что если пользоваться стандартом, то такие исключения надо обрабатывать. L>>Единственный правильный способ обработать такое исключение — записать дамп и упасть. BFE>Упасть — не вариант.
Еще раз, медленно и по буквам. В общем случае восстановление работы программы после критического софтверного сбоя (AV, PVFC, std::out_of_memory, дедлок) невозможно. Ты можешь тешить себя надеждами, что всех перехитрил, но на самом деле ты объегориваешь лишь самого себя, поскольку продолжать работу с программой, которая загнала себя в никто не знает какое состояние, нельзя. Она тебе диск форматнет или кингстоны откроет, и ты не будешь иметь не малейшего представления о факапе, пока вода под койку не потечет.
Ты банально не знаешь, что привело к дедлоку (если бы знал, дедлок бы не случился). Ты не имеешь права делать никакие предположения о возможности и/или безопасности продолжения работы. Period. Единственное разумное действие — упасть с дампом.
BFE>(У вас что, поддержка платная?)
Очень платная и одна из лучших в индустрии. Клиенты в очереди стоят. Только ей практически не приходится иметь дело с дампами и дедлоками.
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Так что если пользоваться стандартом, то такие исключения надо обрабатывать. EP>>Во-первых, какие-то специальные телодвижения не нужны (разве что поставить assert ) — там же в корне std::exception. BFE>assert — это исключительно средство разработки. В дебаг версии на него можно вообще никогда не наткнуться.
1. По хорошему тесты и equivalence partitioning должны были запустить assert у которого существуют пути запуска. Этого конечно проще достичь когда низкоуровневый многопоточный код не раскидан по всей системе, а локализован в отдельном модуле.
2. При необходимости, assert'ы можно включить и в release'е (но нужно помнить о том, что некоторые проверки могут поменять postconditions, например алгоритмическую сложность). Видел подобные assert'ы в release в одной очень популярной программе, с сотнями миллионов установок.
3. Необязательно использовать стандартный assert, например некоторые библиотеки специально используют собственный assert, чтобы дать пользователю больший контроль, например SGI STL.
EP>>Во-вторых, опять-таки — это же явный баг в программе, если уж случилось такое, то неизвестно как там оно дальше пойдёт в разнос. BFE>Скажите, а вот когда происходит exception не связанный с отказом оборудования, это ошибка в программе или нет?
В каком смысле? Для чего вообще используются исключения?
Для простой и "трудноигнорируемой" передачи информации об исключительных ситуациях с нижних уровней, на высшие. Причём по пути исключение может пролететь через 3rd party слой, ничего не знающий про этот тип исключений.
Исключительные ситуации, в моём понимании, это внешние проблемы по отношению к коду, а не его внутренние баги. Например при десериализации структуры внезапно закончился файл — это же не баг кода, да? или например в знаменателях повылазили значения близкие к нулю из-за вырожденности системы, или входные данные в неправильном формате и т.д и т.п.
Здравствуйте, B0FEE664, Вы писали:
L>>А где ты увидел преход на личности? Это опыт. Ничего личного. BFE>Согласно моему опыту, качество архитектурных решений следует выбирать с учётом квалификации членов команды. Архитектурное решение выбранное в команде говорит об уровне квалификации членов этой команды.
То есть исходя из квалификации самого слабого члена команды? Вы на вижуал васике пишете?
BFE>Вы разговариваете сами с собой. Какая ещё однопутная железная дорога? Давайте без демагогических аналогий.
Вот тебе пример — построили однопутную железную дорогу и разъезд на ней, чтобы можно было пропускать встречные поезда. В первый же день оказалось, что обычные до этих мест длинные товарняки на разъезд полностью не влезают. В результате — дедлок и миллионы убытка в день и стоящая раком сеть. Кто виноват — машинист поезда или все же горе-проектировщики разъезда?
Классический пример дедлока. Откатывай/исправляй. Потом попробуем твое решение применить в софте.
L>>Мы работаем в терминах архитектурных решений, разработанных специально для конкретных нужд. Будут это потоки, таймеры или даже вовсе прерывания от устройств, нам совершенно неважно. BFE>Ясно.
Что именно?
L>>И ты с темы не соскакивай. Расскажи, как ты будешь исправлять такой дедлок. BFE>deadlock в реалтайм системе с необратимыми действиями?
Где ты увидел реалтайм? Это просто асинхронная система, единственное жесткое контрактное требование к которой — никогда не показывать юзеру неверных/невалидных данных.
BFE>Очевидно, что один из локов лишний.
Воооооот. То есть архитектура неправильная?
BFE>Оба действия должны лежать быть защищены одним синхронизирующим объектом. А как это относится к теме?
Да вот так, что ты только что признался, что исправить дедлок в реалтайме нельзя. Ура, кажется, мы наконец-то куда-то продвинулись!
BFE>Так или иначе, но исключение произойти может.
Еще раз. Дедлок — это не исключение. Это ошибка в коде программы. Как AV или PVFC. Попытка некоторых его задетектить и обратить в исключение ошибку в коде программы исправить не может.
Причем, в отличие от той же AV или PVFC, для того, чтобы гарантированно обнаруживать дедлоки, да еще и без ложных срабатываний, нужно реализовать весьма сложную систему только для этого. Вроде того, что Lazin пытается сделать. И даже в таком случае она окажется абсолютно бесполезной в случае внешнего для этой системы лока. Затем, даже если предположить, что такая система есть и работает, нужно также гарантировать, что ты можешь безопасно откатить все возможные локи. Я для этого нужно их всех без исключения найти и идентифицировать. И тут возникает дилемма — если ты знаешь, где у тебя может возникнуть дедлок, то почему бы просто не изменить код так, чтобы дедлок не возникал? Причем, на исправление ошибки в коде у тебя уйдет ну 2% времени, нужного для реализации системы обнаружения и обезвреживания дедлоков.
А неизвестный дедлок откатывать нельзя. Ты же не знаешь, как и почему он произошел и какие побочные эффекты возникнут.
Бессмысленное занятие, в общем.
BFE>Значит вам в любом случае, хотите вы этого или нет, придётся, хоть с бубном, хоть с плясками, но откатывать стек до какого-то уровня. И умение обрабатывать ошибочные ситуации определяет ваше умение писать качественный софт.
Ты только что сам наверху написал, что исправить сложившуюся ситуацию откатом стека нельзя. Юлить начинаешь.
Мы вообще исключения не обсуждаем, оставь их в покое.
BFE>Всех возможных ситуаций вы в сложном проекте предусмотреть заранее не сможете, так что если ваша архитектура не включает в себя обработку ошибочных ситуаций, значит у вас получится некачественный продукт, который работает только в тепличных условиях.
Настрадаю в предсказамуса — некачественный продукт получается в основном у тех, кто игнорирует ах... какие серьезные архитектурные косяки ради умозрительной "производительности".
L>>>>Еще раз — исправлять косяки проектирования в рантайме поздно. И в общем случае невозможно. BFE>>>В самом деле, если у вас все данные протаскиваются через одну нитку, то исправить такой архитектурный косяк при нехватки производительности невозможно. L>>Никому не интересна высокая производительность системы, которая не может работать корректно. BFE>А я разве с этим спорю?
Споришь. Система с дедлоками по определению некорректна.
L>>С другой стороны, корректно и стабильно работающую систему, да еще и покрытую серией автотестов, весь косяк которой своидтся к недостаточной производительности, всегда можно смасштабировать. Особенно если ее разработчики такую возможность предусмотрели. BFE>О, да! Знаю я эти сказки.
Ну не повезло тебе, видимо, встретиться с нормальными масштабируемыми системами.
L>>И, чтобы уж добить. У нас есть система, в которой все данные "протаскиваются через одну нитку". Пока что ни один другой продукт на рынке не смог добиться даже 1/1000 от ее производительности и 1/100 от масштабируемости. Угадай, почему? BFE>Это интересная игра: угадай почему чёрный ящик делающий неведомо что, работает лучше, чем другой чёрный ящик.
Я уже писал в этом чати, какой именно черный ящик я разрабатываю. Больше заниматься пенисометрией не намерен.
Здравствуйте, landerhigh, Вы писали:
L>>>А где ты увидел преход на личности? Это опыт. Ничего личного. BFE>>Согласно моему опыту, качество архитектурных решений следует выбирать с учётом квалификации членов команды. Архитектурное решение выбранное в команде говорит об уровне квалификации членов этой команды. L>То есть исходя из квалификации самого слабого члена команды?
Угу. Если человек не может исправить deadlock без изменения архитектуры, то тут уж ничего не поделаешь, приходится заранее под его особенности проектировать архитектуру, раз уж есть ограничения в понимании.
L>Вы на вижуал васике пишете?
нет.
BFE>>Вы разговариваете сами с собой. Какая ещё однопутная железная дорога? Давайте без демагогических аналогий. L>
L>Вот тебе пример — построили однопутную железную дорогу и разъезд на ней, чтобы можно было пропускать встречные поезда. В первый же день оказалось, что обычные до этих мест длинные товарняки на разъезд полностью не влезают. В результате — дедлок и миллионы убытка в день и стоящая раком сеть. Кто виноват — машинист поезда или все же горе-проектировщики разъезда?
L>Классический пример дедлока. Откатывай/исправляй. Потом попробуем твое решение применить в софте.
Ну, раз вы настаиваете на демагогических приёмах, то пожалуйста. Очевидно, что стоимость работ и земли очень высока, иначе вместо короткого разъезда построили бы полноценную двухпутную дорогу. Согласны?
L>>>Мы работаем в терминах архитектурных решений, разработанных специально для конкретных нужд. Будут это потоки, таймеры или даже вовсе прерывания от устройств, нам совершенно неважно. BFE>>Ясно. L>Что именно?
Мне ясен ваш ответ.
BFE>>Очевидно, что один из локов лишний. L>Воооооот. То есть архитектура неправильная?
Как Java не спасает от ошибок программистов, так и обнаружение deadlock'ов не спасает от ошибок архитектуры.
BFE>>Оба действия должны лежать быть защищены одним синхронизирующим объектом. А как это относится к теме? L>Да вот так, что ты только что признался, что исправить дедлок в реалтайме нельзя. Ура, кажется, мы наконец-то куда-то продвинулись!
Что ж. Придётся повторить: если необходимо обеспечить согласованность данных и над первым из данных совершается необратимое действие, то операции над такими данными надо проводить под защитой одного мютекса. Если же, по каким-либо причинам, данные защищаются двумя различными мютексами, то захват обоих мютексов должен производится до начала первой операции. В стандарте даже есть специальная функция для этого.
BFE>>Так или иначе, но исключение произойти может. L>Еще раз. Дедлок — это не исключение.
А я этого и не утверждал.
L>Это ошибка в коде программы.
Зависит исключительно от точки зрения.
L>Как AV или PVFC.
Расшифруйте, пожалуйста.
L>Попытка некоторых его задетектить и обратить в исключение ошибку в коде программы исправить не может.
Ошибку не может, а вот deadlock — может.
L>Причем, в отличие от той же AV или PVFC, для того, чтобы гарантированно обнаруживать дедлоки, да еще и без ложных срабатываний, нужно реализовать весьма сложную систему только для этого.
Если бы это было просто, это давно бы уже сделали и использовали. Это как с указателями. Сначала все ловили баги с не инициализированными указателями, потом придумали smart указатели и ценой "чудовищного" оверхеда сегодня эта проблема ушла в небытие.
L>Вроде того, что Lazin пытается сделать. И даже в таком случае она окажется абсолютно бесполезной в случае внешнего для этой системы лока. Затем, даже если предположить, что такая система есть и работает, нужно также гарантировать, что ты можешь безопасно откатить все возможные локи. Я для этого нужно их всех без исключения найти и идентифицировать. И тут возникает дилемма — если ты знаешь, где у тебя может возникнуть дедлок, то почему бы просто не изменить код так, чтобы дедлок не возникал?
Потому, что это может оказаться невыгодно с точки зрения скорости.
L>Причем, на исправление ошибки в коде у тебя уйдет ну 2% времени, нужного для реализации системы обнаружения и обезвреживания дедлоков.
Это зависит от сложности проекта. К тому же, если уже есть готовая библиотека...
L>А неизвестный дедлок откатывать нельзя. Ты же не знаешь, как и почему он произошел и какие побочные эффекты возникнут. L>Бессмысленное занятие, в общем.
Если система толерантна к исключениям, то нет ничего сложного.
BFE>>Значит вам в любом случае, хотите вы этого или нет, придётся, хоть с бубном, хоть с плясками, но откатывать стек до какого-то уровня. И умение обрабатывать ошибочные ситуации определяет ваше умение писать качественный софт. L>Ты только что сам наверху написал, что исправить сложившуюся ситуацию откатом стека нельзя. Юлить начинаешь. L>Мы вообще исключения не обсуждаем, оставь их в покое.
Я говорю про решение, а не про что-то ещё.
L>Споришь. Система с дедлоками по определению некорректна.
Система, которая обнаруживает возможность deadlock'а на следующем шаге и бросает исключение до наступления состояния взаимной блокировки по определению не имеет deadlock'ов.
L>Ну не повезло тебе, видимо, встретиться с нормальными масштабируемыми системами.
Тут дело не в везении.
L>Я уже писал в этом чати, какой именно черный ящик я разрабатываю. Больше заниматься пенисометрией не намерен.
Ну так и не надо было начинать.
Нет, просто система аварийного охлаждения сломалась и активная зона перегрелась, ничего страшного, придется управляющие стержни заменить и долить немного тяжелой воды
L>Ой. Все, что от нормальной библиотеки требуется — это четкая гарантия thread safety. Должно быть четко документировано, какие методы безусловно безопасны, какие — безопасны при условии того, что они работают с разными данными, а какие требуют блокировки. Еще необходимо четко описать, как именно и из какого потока вызываеются колбеки. L>Как пользователь 100500 разных библиотек, насмотревшийся всякго, попрошу — пожалайста, не надо делать ничего больше! Для библиотеки крайне важно не совершать никаких ненаблюдаемых извне и не запрошенных явно действий.
а) у меня не нормальная библиотека а библиотека синхронизации
б) я не собираюсь включать это по умолчанию, это механизм, который можно врубить дефайном, в рамках специального билда
г) твой аргумент — инвалид
L>>>Они как минимум убирают необходимость в 100500 явных блокировок. L>>atomic-и это тоже синхронизация L>В идеале atomic это просто объект данных, который гарантированно можно целиком записать за одну операцию и при этом у него не будет внешне наблюдаемого промежуточного "недозаписанного" состояния.
performance wise это примерно то же самое что и лок на короткое время, только тебе еще нужно думать о таких вещах как false sharing и выравнивание
с точки зрения корректности я с тобой не спорил, если что
L>>>Ты кагбы можешь мне это не рассказывать, для меня IEC61850, MODBUS, BACNET, DNP3 и прочие страшные слова — вовсе не пустой звук. Но мы подобных проблем почему-то не имеем. L>>софт о котором я говорил не имеет подобных проблем, просто приведен в качестве примера сервиса, обрабатывающего столько данных, сколько по твоему не бывает он используется, например, в ЦДУ СО ЕЭС (судя по использованным аббревиатурам ты должен знать что это такое) для сбора всей телеметрии, какая только есть
L>Эээ, это тебе в СО ЕЭС показалось, что там много данных? А я-то уж было напрягся
В ЦДУ стекаются данные со всей энергосистемы РФ, я уже не помню детали, но у них там было очень много телеизмерений/телесигналов и менялись они довольно шустро.
Здравствуйте, B0FEE664, Вы писали:
L>>То есть исходя из квалификации самого слабого члена команды? BFE>Угу. Если человек не может исправить deadlock без изменения архитектуры, то тут уж ничего не поделаешь, приходится заранее под его особенности проектировать архитектуру, раз уж есть ограничения в понимании.
Правильная архитектура исключает образование дедлоков. При чем тут абстрактный человек в вакууме, который не в состоянии?
L>>Вы на вижуал васике пишете? BFE>нет.
А судя по ответам ниже — таки да
L>>Классический пример дедлока. Откатывай/исправляй. Потом попробуем твое решение применить в софте. BFE>Ну, раз вы настаиваете на демагогических приёмах, то пожалуйста. Очевидно, что стоимость работ и земли очень высока, иначе вместо короткого разъезда построили бы полноценную двухпутную дорогу. Согласны?
Вот это и есть демагогия. Есть много причин, по которых строят однопутную дорогу. Исправлять-то как будешь?
BFE>>>Очевидно, что один из локов лишний. L>>Воооооот. То есть архитектура неправильная? BFE>Как Java не спасает от ошибок программистов, так и обнаружение deadlock'ов не спасает от ошибок архитектуры.
О!
BFE>>>Оба действия должны лежать быть защищены одним синхронизирующим объектом. А как это относится к теме? L>>Да вот так, что ты только что признался, что исправить дедлок в реалтайме нельзя. Ура, кажется, мы наконец-то куда-то продвинулись! BFE>Что ж. Придётся повторить: если необходимо обеспечить согласованность данных и над первым из данных совершается необратимое действие, то операции над такими данными надо проводить под защитой одного мютекса.
Иными словами, нужно включить моск, а не надеяться, что чудо-либа отловит дедлок...
BFE>>>Так или иначе, но исключение произойти может. L>>Еще раз. Дедлок — это не исключение. BFE>А я этого и не утверждал.
А зачем притащил сюда исключения?
L>>Это ошибка в коде программы. BFE>Зависит исключительно от точки зрения.
Дедлоки возникают исключительно в результате ошбики в коде программы. Независимо от точек зрения.
L>>Как AV или PVFC. BFE>Расшифруйте, пожалуйста.
А ты точно на с++ пишешь?
L>>Попытка некоторых его задетектить и обратить в исключение ошибку в коде программы исправить не может. BFE>Ошибку не может, а вот deadlock — может.
Ты уже исправил дедлоки, которые я в пример привел?
L>>Причем, в отличие от той же AV или PVFC, для того, чтобы гарантированно обнаруживать дедлоки, да еще и без ложных срабатываний, нужно реализовать весьма сложную систему только для этого. BFE>Если бы это было просто, это давно бы уже сделали и использовали. Это как с указателями. Сначала все ловили баги с не инициализированными указателями, потом придумали smart указатели и ценой "чудовищного" оверхеда сегодня эта проблема ушла в небытие.
Отучаемся говорить за "всех". Не "все" ловили баги. Те, кто ниасилил голые указатели, так же прекрасно сегодня ловят NullPointerException. И умные указатели вообще не для того придумали, к слову.
L>>Вроде того, что Lazin пытается сделать. И даже в таком случае она окажется абсолютно бесполезной в случае внешнего для этой системы лока. Затем, даже если предположить, что такая система есть и работает, нужно также гарантировать, что ты можешь безопасно откатить все возможные локи. Я для этого нужно их всех без исключения найти и идентифицировать. И тут возникает дилемма — если ты знаешь, где у тебя может возникнуть дедлок, то почему бы просто не изменить код так, чтобы дедлок не возникал? BFE>Потому, что это может оказаться невыгодно с точки зрения скорости.
Кто о чем, а ты о скорости. Ты, кстати, в курсе оверхеда от сработавшего исключения? Что там от твоей скорости останется? Ну и опять же, понятие скорости применимо лишь к корректно работающей системе. Система, допускающая дедлоки — некорректна.
L>>Причем, на исправление ошибки в коде у тебя уйдет ну 2% времени, нужного для реализации системы обнаружения и обезвреживания дедлоков. BFE>Это зависит от сложности проекта. К тому же, если уже есть готовая библиотека...
То есть у тебя настолько сложная система, что ты не знаешь, есть там дедлоки или нет? И ты планируешь это резко пофиксить за счет магической либы?
L>>А неизвестный дедлок откатывать нельзя. Ты же не знаешь, как и почему он произошел и какие побочные эффекты возникнут. L>>Бессмысленное занятие, в общем. BFE>Если система толерантна к исключениям, то нет ничего сложного.
Дедлок — это не исключение. Это ошибка в программе.
BFE>>>Значит вам в любом случае, хотите вы этого или нет, придётся, хоть с бубном, хоть с плясками, но откатывать стек до какого-то уровня. И умение обрабатывать ошибочные ситуации определяет ваше умение писать качественный софт. L>>Ты только что сам наверху написал, что исправить сложившуюся ситуацию откатом стека нельзя. Юлить начинаешь. L>>Мы вообще исключения не обсуждаем, оставь их в покое. BFE>Я говорю про решение, а не про что-то ещё.
То есть ты заранее спланировал систему так, что ты знаешь, что DoSomething may deadlock indeed.
Вопросы:
Почему бы не перепроектировать систему так, чтобы дедлока не было, т.к ты о нем знаешь?
Кто-то что-то о "производительности" говорил. Ну-ну.
В дедлоке всегда виноваты двое, кроме совсем уж вырожденных случаев, когда тред лочит сам себя. (Кстати, в этом случае вышеприведенный код прекрасно будет крутить бесконечный цикл. Бугагага) Что ты со вторым тредом делать будешь? А вдруг он надолго забрал лок? А вдруг там очередь из таких же тредов и все крутят исключения в цикле? Отличная получится производительность, ничего не скажешь
DoSomethingThatMayDeadlock обязана уметь полностью откатить состояние абсолютно всех затронутых объектов данных при вообще любом (не только DeadlockException) исключении, которая она выпускает наружу. А в общем случае, особенно когда все треды активно взаимодействуют друг с другом, это невозможно в принципе.
L>>Споришь. Система с дедлоками по определению некорректна. BFE>Система, которая обнаруживает возможность deadlock'а на следующем шаге и бросает исключение до наступления состояния взаимной блокировки по определению не имеет deadlock'ов.
Что-то мне это напоминает. А! Это как отделение милиции, в котором не регистрируют мелкие карманные кражи, чтобы статистику не портить
BFE>Угу. Если человек не может исправить deadlock без изменения архитектуры, то тут уж ничего не поделаешь, приходится заранее под его особенности проектировать архитектуру, раз уж есть ограничения в понимании.
Есть такая штука — try_lock называется. Не решение всех проблем, однако в описанном тобой случае, с помощью этого метода можно обрабатывать такие ошибки (try_lock + exponential backoff или yield с исключением по таймауту).
MZ>Про графы: если делать по уму, то по идее граф должен выродиться MZ>в линейный список мьютексов. Т.е. я хочу сказать, что то, что вы MZ>делаете, обычно делают (видимо) проще -- лочат мьютексы в строго MZ>определённом порядке.
Это и нужно для того, чтобы проверить, что лочат в строго определенном порядке.
Здравствуйте, Lazin, Вы писали:
L>>Как пользователь 100500 разных библиотек, насмотревшийся всякго, попрошу — пожалайста, не надо делать ничего больше! Для библиотеки крайне важно не совершать никаких ненаблюдаемых извне и не запрошенных явно действий.
L>а) у меня не нормальная библиотека а библиотека синхронизации
Дело в том, что я прячу отдельные мьютексы за интерфейсом и говорю что объекты можно лочить так и так. Пользователь может решить (ошибочно), что он лочит разные объекты и дедлок невозможен в принципе, даже если он это делает в разном порядке, так как объекты реально разные и его архитектура это гарантирует, это и было бы так, если бы он использовал мьютексы напрямую, но у меня может получиться конфликт и возникнет дедлок.
А это тогда о чем?
L>б) я не собираюсь включать это по умолчанию, это механизм, который можно врубить дефайном, в рамках специального билда L>г) твой аргумент — инвалид
Валид-валид.
L>>В идеале atomic это просто объект данных, который гарантированно можно целиком записать за одну операцию и при этом у него не будет внешне наблюдаемого промежуточного "недозаписанного" состояния.
L>performance wise это примерно то же самое что и лок на короткое время, только тебе еще нужно думать о таких вещах как false sharing и выравнивание
Это весьма implementation (platform) specific. в контексте данной дискуссии иррелевантно.
L>>Эээ, это тебе в СО ЕЭС показалось, что там много данных? А я-то уж было напрягся
L>В ЦДУ стекаются данные со всей энергосистемы РФ, я уже не помню детали, но у них там было очень много телеизмерений/телесигналов и менялись они довольно шустро.
BFE>Ну так не в скорости проблема. Проблема в том, что в разные порты надо посылать команды с разными промежутками времени и ждать ответа тоже с разными интервалами.
Для этого потоки не нужны. Reactor-based model украдена задолго до нас. У вас классический пример сервера (просто взгляните на ваш "одноядерный ARM" как на сервер, клиентами которого выступают моторы и приборные панели).
L>Дело в том, что я прячу отдельные мьютексы за интерфейсом и говорю что объекты можно лочить так и так. Пользователь может решить (ошибочно), что он лочит разные объекты и дедлок невозможен в принципе, даже если он это делает в разном порядке, так как объекты реально разные и его архитектура это гарантирует, это и было бы так, если бы он использовал мьютексы напрямую, но у меня может получиться конфликт и возникнет дедлок.
L>А это тогда о чем?
Я не вижу противоречий. Есть описание того, как это нужно использовать и определенное заранее поведение.
L>>>Эээ, это тебе в СО ЕЭС показалось, что там много данных? А я-то уж было напрягся
L>>В ЦДУ стекаются данные со всей энергосистемы РФ, я уже не помню детали, но у них там было очень много телеизмерений/телесигналов и менялись они довольно шустро.
L>Это ты по циферкам на экранах оценил?
Я работал в компании, сделавший для них scada систему. Лол.
) — там же в корне std::exception. 
