Re[25]: Deadlock-prevention алгоритм
От: landerhigh Пират  
Дата: 02.07.14 21:14
Оценка:
Здравствуйте, Lazin, Вы писали:

L>>А это тогда о чем?


L>Я не вижу противоречий. Есть описание того, как это нужно использовать и определенное заранее поведение.


Вот именно. Либа должна делать только это и ничего больше.

L>>>>Эээ, это тебе в СО ЕЭС показалось, что там много данных? А я-то уж было напрягся


L>>>В ЦДУ стекаются данные со всей энергосистемы РФ, я уже не помню детали, но у них там было очень много телеизмерений/телесигналов и менялись они довольно шустро.


L>>Это ты по циферкам на экранах оценил?


L>Я работал в компании, сделавший для них scada систему. Лол.


Тогда должен представлять себе количество тегов и нагрузочную способность по алармам, а также частоту обновления. Там на самом деле ничего из ряда вон выходящего нет.
www.blinnov.com
Re[26]: Deadlock-prevention алгоритм
От: Lazin Россия http://evgeny-lazin.blogspot.com
Дата: 03.07.14 10:40
Оценка:
L>>Я не вижу противоречий. Есть описание того, как это нужно использовать и определенное заранее поведение.

L>Вот именно. Либа должна делать только это и ничего больше.


Ну так она это и делает, я правда не понимаю что тебе не нравится! Есть lock layer, явно сказано, что его нельзя использовать рекурсивно никогда Можно собрать дебаг версию, которая будет детектить дедлоки.

L>>Я работал в компании, сделавший для них scada систему. Лол.


L>Тогда должен представлять себе количество тегов и нагрузочную способность по алармам, а также частоту обновления. Там на самом деле ничего из ряда вон выходящего нет.


Каких еще тегов?
Re[27]: Deadlock-prevention алгоритм
От: landerhigh Пират  
Дата: 03.07.14 11:12
Оценка:
Здравствуйте, Lazin, Вы писали:

L>>Вот именно. Либа должна делать только это и ничего больше.


L>Ну так она это и делает, я правда не понимаю что тебе не нравится! Есть lock layer, явно сказано, что его нельзя использовать рекурсивно никогда


Этого достаточно.

L>Можно собрать дебаг версию, которая будет детектить дедлоки.


А это лишнее. Если архитектура допускает дедлоки, то гарантированно отловить их все во время тестирования невозможно. Особенно в дебаг версии. Более того, рискуешь огрести "Ваша либа прохлопала дедлок, который вылез в продакшене и в результате у нас убытков на 100500 денег".

L>>>Я работал в компании, сделавший для них scada систему. Лол.


L>>Тогда должен представлять себе количество тегов и нагрузочную способность по алармам, а также частоту обновления. Там на самом деле ничего из ряда вон выходящего нет.


L>Каких еще тегов?


Понятно, проехали.
www.blinnov.com
Re[28]: Deadlock-prevention алгоритм
От: Lazin Россия http://evgeny-lazin.blogspot.com
Дата: 03.07.14 12:23
Оценка:
L>>Можно собрать дебаг версию, которая будет детектить дедлоки.
L>А это лишнее. Если архитектура допускает дедлоки, то гарантированно отловить их все во время тестирования невозможно. Особенно в дебаг версии. Более того, рискуешь огрести "Ваша либа прохлопала дедлок, который вылез в продакшене и в результате у нас убытков на 100500 денег".

Ты вообще смотрел как это все работает? Syncope не ищет дедлоки между отдельными локами (так как, как ты правильно заметил, это мало что даст), вместо этого, либа пытается искать некорректные паттерны использования, которые могут привести к дедлоку. Т.е. deadlock detector в syncope на самом деле просто проверяет — допускает ли архитектура дедлоки или нет. Для того, чтобы выполнить свою задачу, ему не нужно чтобы дедлок реально произошел. Ты можешь залочить что-нибудь в одном потоке, а потом, через 10 минут залочить что-нибудь еще в другом потоке в неправильном порядке и библиотека это обнаружит, а традиционный deadlock detector — нет, так как реальный дедлок в этом случае не произойдет.

L>>>>Я работал в компании, сделавший для них scada систему. Лол.


L>>>Тогда должен представлять себе количество тегов и нагрузочную способность по алармам, а также частоту обновления. Там на самом деле ничего из ряда вон выходящего нет.


L>>Каких еще тегов?


L>Понятно, проехали.


В нашей SCADA системе теги назывались по другому, если я конечно правильно понял о чем ты. Таких "тегов" было порядка 10К, точные цифры — сколько раз в секунду менялся каждый из них я, само собой, не помню но уж точно чаще 10-ти
Даже в вебе часто получаютются нагрузки порядка 100К req/sec. Всякие редисы/монги по твоему для чего еще нужны?
Re[29]: Deadlock-prevention алгоритм
От: landerhigh Пират  
Дата: 03.07.14 13:06
Оценка:
Здравствуйте, Lazin, Вы писали:

L>Ты вообще смотрел как это все работает?


Торжественно клянусь внимательно рассмотреть в ближайшее время
я так понимаю, ты сделал статический анализ?

L>>>>>Я работал в компании, сделавший для них scada систему. Лол.


L>>>Каких еще тегов?


L>>Понятно, проехали.


L>В нашей SCADA системе теги назывались по другому, если я конечно правильно понял о чем ты. Таких "тегов" было порядка 10К, точные цифры — сколько раз в секунду менялся каждый из них я, само собой, не помню но уж точно чаще 10-ти


Там нет показателей, которые меняются так часто. Особенно при съеме таких интересных индикаторов, как счетчики энергии. Есть показатели, которые могут меняться с миллисекундным разрешением, но их скада считывает несколько другими механизмами, нежели поллингом.

10К тегов — для скады масштаб маленький, почти игрушечный.
www.blinnov.com
Re[29]: Deadlock-prevention алгоритм
От: landerhigh Пират  
Дата: 03.07.14 13:37
Оценка:
Здравствуйте, Lazin, Вы писали:

L>Ты вообще смотрел как это все работает? Syncope не ищет дедлоки между отдельными локами (так как, как ты правильно заметил, это мало что даст), вместо этого, либа пытается искать некорректные паттерны использования, которые могут привести к дедлоку. Т.е. deadlock detector в syncope на самом деле просто проверяет — допускает ли архитектура дедлоки или нет. Для того, чтобы выполнить свою задачу, ему не нужно чтобы дедлок реально произошел. Ты можешь залочить что-нибудь в одном потоке, а потом, через 10 минут залочить что-нибудь еще в другом потоке в неправильном порядке и библиотека это обнаружит, а традиционный deadlock detector — нет, так как реальный дедлок в этом случае не произойдет.


Погоди, она ж все равно требует, чтобы все эти события произошли в рантайме. Как ты отметил, необязательно вызвать лок, важно, чтобы были зафискированы опасные пересечения векторов блокировок.
Это, действительно, лучше, чем сидеть и ждать наступления дедлока, но все равно дает недостаточные гарантии.
Кроме того, мне кажется, что возможны false positives.
www.blinnov.com
Re[30]: Deadlock-prevention алгоритм
От: Lazin Россия http://evgeny-lazin.blogspot.com
Дата: 03.07.14 14:13
Оценка:
L>Погоди, она ж все равно требует, чтобы все эти события произошли в рантайме. Как ты отметил, необязательно вызвать лок, важно, чтобы были зафискированы опасные пересечения векторов блокировок.

Да, все фиксируется в рантайме. Но тут фишка в том, что все это не должно обязательно пересекаться во времени. Все может вообще в одном потоке выполняться и неправильный порядок захвата lock layer-ов будет зафиксирован. В этом то и была идея изначально. Уровни блокировок нужны для того, чтобы обозначить эти самые уровни блокировок в приложении явным образом + это позволяет реализовать мой R/W мьютекс + упрощает проверки в рантайме. Текущая реализация по мотивам того, что предложил sokel (еще незакомиченая) для 16 уровней вложенности блокировок добавляет примерно 20% накладных расходов на проверки. В реальной программе должно быть 1-2 уровня, едва ли больше. Так что эти проверки можно считать практически бесплатными.

По поводу статических проверок — я не могу это реализовать по понятным причинам. TMP использовать не получится, так как стек вызовов не существует в compile time. И вообще, статический анализ vs рантайм анализ, это ложная дихотомия. Не все возможно проверить статически, какая-то информация есть только в рантайме, с другой стороны — в рантайме может не вызываться какой-то код, содержащий ошибку, поэтому, статический и динамический анализ могут хорошо дополнять друг друга, но уж никак не противопоставляться.

L>Это, действительно, лучше, чем сидеть и ждать наступления дедлока, но все равно дает недостаточные гарантии.

L>Кроме того, мне кажется, что возможны false positives.

Смотря что считать false positive. Если, допустим, есть 2 уровня и приложение лочит эти уровни сначала в одном порядке один раз и больше никогда так не делает (допустим во время инициализации), а потом все время лочит в другом порядке, то это false positive, да. Но я сомневаюсь в том, что защищаться от таких вот false positives хоть сколько нибудь практично.
Re[31]: Deadlock-prevention алгоритм
От: landerhigh Пират  
Дата: 03.07.14 18:27
Оценка:
Здравствуйте, Lazin, Вы писали:

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


L>Да, все фиксируется в рантайме. Но тут фишка в том, что все это не должно обязательно пересекаться во времени. Все может вообще в одном потоке выполняться и неправильный порядок захвата lock layer-ов будет зафиксирован. В этом то и была идея изначально.


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

L>>Это, действительно, лучше, чем сидеть и ждать наступления дедлока, но все равно дает недостаточные гарантии.

L>>Кроме того, мне кажется, что возможны false positives.

L>Смотря что считать false positive. Если, допустим, есть 2 уровня и приложение лочит эти уровни сначала в одном порядке один раз и больше никогда так не делает (допустим во время инициализации), а потом все время лочит в другом порядке, то это false positive, да. Но я сомневаюсь в том, что защищаться от таких вот false positives хоть сколько нибудь практично.


Я вполне могу допустить валидные случаи, когда одни и те же пары мьютексов лочатся в разных порядках в одном и том же или разных тредах, но не вызывают дедлока, т.к. такое поведение является предусмотренным архитектурой. Будет честный false positive.
www.blinnov.com
Re[32]: Deadlock-prevention алгоритм
От: Lazin Россия http://evgeny-lazin.blogspot.com
Дата: 04.07.14 09:09
Оценка:
L>Опасность дедлоков в том, что в теплице при тестировании они могут не вылезать. То есть может быть такое условие, но вылезает оно только после свистка членистоногово после непродолжитльных осадков жидкой формы в четвертый день недели. То есть неправильный порядок блокировки может никак себя не выдать даже с этой либой, что бы кто ни делал.

И решения у этой проблемы все равно нет.

L>Я вполне могу допустить валидные случаи, когда одни и те же пары мьютексов лочатся в разных порядках в одном и том же или разных тредах, но не вызывают дедлока, т.к. такое поведение является предусмотренным архитектурой. Будет честный false positive.


Ну я же явно оговариваю, что так делать нельзя. Так что здесь все ок.
Re[10]: Deadlock-prevention алгоритм
От: B0FEE664  
Дата: 04.07.14 09:58
Оценка:
Здравствуйте, SkyDance, Вы писали:

BFE>>Ну так не в скорости проблема. Проблема в том, что в разные порты надо посылать команды с разными промежутками времени и ждать ответа тоже с разными интервалами.

SD>Для этого потоки не нужны. Reactor-based model украдена задолго до нас. У вас классический пример сервера (просто взгляните на ваш "одноядерный ARM" как на сервер, клиентами которого выступают моторы и приборные панели).

Если бы у нас была реалтайм система, то так бы и пришлось делать. Да, сначала так и пытались, но оказалось, что это довольно сложный патерн в плане добавления в него новых событий: один loop должен знать о всех событиях системы, что оказалось очень неудобным, так как у нас несколько раз поменялись подключаемые устройства и их характеристики. Программа должна работать в разных конфигурациях оборудования. Оказалось проще под каждое устройство написать свой программный модуль со своими циклами обработки данных, чем иметь один динамический изменяемый event loop.

PS Ходить по воде и разрабатывать программы, следуя спецификации, очень просто… если они заморожены.
И каждый день — без права на ошибку...
Re[34]: Deadlock-prevention алгоритм
От: B0FEE664  
Дата: 04.07.14 10:45
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>>>То есть исходя из квалификации самого слабого члена команды?

BFE>>Угу. Если человек не может исправить deadlock без изменения архитектуры, то тут уж ничего не поделаешь, приходится заранее под его особенности проектировать архитектуру, раз уж есть ограничения в понимании.
L>Правильная архитектура исключает образование дедлоков. При чем тут абстрактный человек в вакууме, который не в состоянии?
Вот поэтому "правильная" архитектура исключает образование дедлоков.

L>>>Вы на вижуал васике пишете?

BFE>>нет.
L>А судя по ответам ниже — таки да
Двенадцать лет назад я закончил писать на Visual Basic тестовые примеры для OCX Active X контролов, что сам же и разрабатывал. Они, кстати, хорошо продавались.

L>>>Классический пример дедлока. Откатывай/исправляй. Потом попробуем твое решение применить в софте.

BFE>>Ну, раз вы настаиваете на демагогических приёмах, то пожалуйста. Очевидно, что стоимость работ и земли очень высока, иначе вместо короткого разъезда построили бы полноценную двухпутную дорогу. Согласны?
L>Вот это и есть демагогия.
Разуется этот демагогия: искать решения для компьютерной программы в мире реальных вещей.
L>Есть много причин, по которых строят однопутную дорогу. Исправлять-то как будешь?
Так вы согласны с утверждением о стоимости?

BFE>>Что ж. Придётся повторить: если необходимо обеспечить согласованность данных и над первым из данных совершается необратимое действие, то операции над такими данными надо проводить под защитой одного мютекса.

L>Иными словами, нужно включить моск, а не надеяться, что чудо-либа отловит дедлок...
Я бы советовал вообще не отключать "моск" при программировании.

L>А зачем притащил сюда исключения?

Для примера и конкретики.

L>>>Это ошибка в коде программы.

BFE>>Зависит исключительно от точки зрения.
L>Дедлоки возникают исключительно в результате ошбики в коде программы. Независимо от точек зрения.
Какие ваши доказательства?

L>>>Как AV или PVFC.

BFE>>Расшифруйте, пожалуйста.
L>А ты точно на с++ пишешь?
Да.

L>>>Попытка некоторых его задетектить и обратить в исключение ошибку в коде программы исправить не может.

BFE>>Ошибку не может, а вот deadlock — может.
L>Ты уже исправил дедлоки, которые я в пример привел?
Это вы о физическом мире?

L>Отучаемся говорить за "всех". Не "все" ловили баги. Те, кто ниасилил голые указатели, так же прекрасно сегодня ловят NullPointerException. И умные указатели вообще не для того придумали, к слову.

Тот, кто не ловил такие баги, тот не отлаживал чужие программы. Тем, кто не отлаживал чужие программы, тяжело даётся понимание нестандартных архитектурных решений.

L>Кто о чем, а ты о скорости. Ты, кстати, в курсе оверхеда от сработавшего исключения? Что там от твоей скорости останется?

Да. От задачи зависит.
L>Ну и опять же, понятие скорости применимо лишь к корректно работающей системе. Система, допускающая дедлоки — некорректна.
Система не допускающая попадания в состояние deadlock'а не допускает deadlock'ов.

L>То есть у тебя настолько сложная система, что ты не знаешь, есть там дедлоки или нет? И ты планируешь это резко пофиксить за счет магической либы?

Я говорю о системе, которая обнаруживает состояние близкое к deadlock'у во время исполнения.

L>Дедлок — это не исключение. Это ошибка в программе.

Система не допускающая попадания в состояние deadlock'а не допускает deadlock'ов.

L>Я так понимаю, ты хочешь что-то вроде этого.

да.
L>
L>while (true)
L>try
L>{
L>  DoSomethingThatMayDeadlock();
L>  break;
L>}
L>catch (const DeadlockException& )
L>{
L>  Log << cat::WARNING << "Deadlocked. Try again.";
L>}
L>


L>То есть ты заранее спланировал систему так, что ты знаешь, что DoSomething may deadlock indeed.

L>Вопросы:
L>

    L>
  1. Почему бы не перепроектировать систему так, чтобы дедлока не было, т.к ты о нем знаешь?
    Т.к. перепроектирование системы может потребовать неоправданных затрат.

    L>
  2. Кто-то что-то о "производительности" говорил. Ну-ну.
    О какой производительности говорите вы, сведя задачу к однопоточному исполнению?

    L>
  3. В дедлоке всегда виноваты двое, кроме совсем уж вырожденных случаев, когда тред лочит сам себя. Что ты со вторым тредом делать будешь? (Кстати, в этом случае вышеприведенный код прекрасно будет крутить бесконечный цикл. Бугагага)
    А вот это реальная бага.

    L>А вдруг он надолго забрал лок?

    От однопоточного исполнения отличия не будет.

    L>А вдруг там очередь из таких же тредов и все крутят исключения в цикле? Отличная получится производительность, ничего не скажешь

    При правильном проектировании проблема livelock'а не возникнет.

    L>
  4. DoSomethingThatMayDeadlock обязана уметь полностью откатить состояние абсолютно всех затронутых объектов данных при вообще любом (не только DeadlockException) исключении, которая она выпускает наружу. А в общем случае, особенно когда все треды активно взаимодействуют друг с другом, это невозможно в принципе.
    L>
Т.е. вы пишите программы, которые не бросают исключений?

L>>>Споришь. Система с дедлоками по определению некорректна.

BFE>>Система, которая обнаруживает возможность deadlock'а на следующем шаге и бросает исключение до наступления состояния взаимной блокировки по определению не имеет deadlock'ов.
L>Что-то мне это напоминает. А! Это как отделение милиции, в котором не регистрируют мелкие карманные кражи, чтобы статистику не портить
Опять демагогия.
И каждый день — без права на ошибку...
Re[34]: Deadlock-prevention алгоритм
От: B0FEE664  
Дата: 04.07.14 10:48
Оценка:
Здравствуйте, Lazin, Вы писали:

BFE>>Угу. Если человек не может исправить deadlock без изменения архитектуры, то тут уж ничего не поделаешь, приходится заранее под его особенности проектировать архитектуру, раз уж есть ограничения в понимании.

L>Есть такая штука — try_lock называется. Не решение всех проблем, однако в описанном тобой случае, с помощью этого метода можно обрабатывать такие ошибки (try_lock + exponential backoff или yield с исключением по таймауту).

Вообще-то локальной информации не достаточно для обнаружения deadlock'а. Чем тут try_lock поможет?
И каждый день — без права на ошибку...
Re[30]: Deadlock-prevention алгоритм
От: B0FEE664  
Дата: 04.07.14 11:14
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

BFE>>>>Так что если пользоваться стандартом, то такие исключения надо обрабатывать.

EP>>>Во-первых, какие-то специальные телодвижения не нужны (разве что поставить assert ) — там же в корне std::exception.
BFE>>assert — это исключительно средство разработки. В дебаг версии на него можно вообще никогда не наткнуться.

EP>1. По хорошему тесты и equivalence partitioning должны были запустить assert у которого существуют пути запуска. Этого конечно проще достичь когда низкоуровневый многопоточный код не раскидан по всей системе, а локализован в отдельном модуле.

Мне кажется или это высказывание равносильно предложению: давайте отловим все баги в системе?

EP>2. При необходимости, assert'ы можно включить и в release'е (но нужно помнить о том, что некоторые проверки могут поменять postconditions, например алгоритмическую сложность). Видел подобные assert'ы в release в одной очень популярной программе, с сотнями миллионов установок.

Количество установок не говорит о качестве когда. Может оттого они и оставили assert'ы, что отладить не смогли.

EP>3. Необязательно использовать стандартный assert, например некоторые библиотеки специально используют собственный assert, чтобы дать пользователю больший контроль, например SGI STL.

Да и? А я вот видел, как предлагали assert в релизе заменить бросанием эксепшена.

Я же не про это говорю. Я говорю, что если есть код, который содержит в себе throw, то должен быть и catch, который его ловит даже если разработчик думает, что такое никогда не произойдёт. Если вы не собираетесь выкинуть ваш код, то будьте готовы, что завтра ваш код кто-то подправит и исключение, таки, будет брошено.

EP>Исключительные ситуации, в моём понимании, это внешние проблемы по отношению к коду, а не его внутренние баги. Например при десериализации структуры внезапно закончился файл — это же не баг кода, да? или например в знаменателях повылазили значения близкие к нулю из-за вырожденности системы, или входные данные в неправильном формате и т.д и т.п.


"в знаменателях повылазили значения близкие к нулю из-за вырожденности системы"
— разве это не баг в программе?

Если входные данные в неправильном формате приводят к состоянию deadlock'а, то это ошибка в программе?
И каждый день — без права на ошибку...
Re[35]: Deadlock-prevention алгоритм
От: Lazin Россия http://evgeny-lazin.blogspot.com
Дата: 04.07.14 11:30
Оценка: 5 (1)
BFE>Вообще-то локальной информации не достаточно для обнаружения deadlock'а. Чем тут try_lock поможет?

Если ты знаешь что во время захвата какого-то мьютекса может произойти дедлок, например, в callback-е, то можно захватывать его через try_lock, в некоторых случаях и обрабатывать ошибки. Что-то вроде этого:

Допустим, в приложении два мьютекса — mutex1 и mutex2. Они захватываются всегда именно в таком порядке — сначала mutex1 а потом mutex2, либо сразу mutex2 без захвата mutex1. Теперь представь, что у нас есть такая ф-я:

void do_something() {
    lock_guard<mutex> g(mutex1);
    ...do something under lock...
}


Пользователь должен вызывать ее в контексте, когда ни один лок не захвачен, иначе мы получим deadlock. Но допустим, мы используем эту ф-ю как callback в каком-то коде и там она дергается в другом контексте — в котором уже захвачен mutex2 и допустим. Может быть так, что код действительно должен вызывать callback под локом mutex2, в этом случае туда нельзя передавать именно этот callback. Можно его немного переделать, вот так:

void do_something() {
    YieldBackoff backoff(100/*times*/, /*for*/chrono::milliseconds(100));
    unique_lock<mutex> g(mutex1, defer_lock);
    while(!g.try_lock()) {
        backoff();
    }
    ...do something under lock...
}


Переменная backoff это backoff стратегия, после определенного количества вызовов она выкинет исключение и вызов callback-а завершится исключительной ситуацией а не взаимной блокировкой, что лучше.
Re[30]: Deadlock-prevention алгоритм
От: B0FEE664  
Дата: 04.07.14 11:30
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

BFE>>А что можно сказать про незапланированный deadlock?

EP>Это ошибка в коде
BFE>>Всё. Висим. Точка. Речь о том, чтобы в принципе избежать такой ситуации.
EP>Избежать deadlock'а или чего?
Т.е. вы считаете, что можно избежать всех deadlock'ов во всех возможных системах и исправить такие ошибки?

EP>Так мы же и так рассматриваем ситуацию, которой в корректной программе быть не должно. И соответственно раз произошёл deadlock, "то и не такое может произойти"

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

EP>>>или что ещё хуже — livelock.

BFE>>livelock возможен, но и с ним понятно как бороться — отдавать время другим ниткам из той нитки, что deadlock обнаружила (после снятия всех блокировок). Если так действовать, то livelock возможен только при перегрузке системы.
EP>Незапланированный deadlock возможен только в коде с багом, точно также как и livelock.
Не бывает сложных систем без ошибок.
DoS-атака возможна даже на сервер работающий без ошибок. Чем DoS не livelock?

EP>Раз уж мы получили deadlock, то почему при раскрутке стэка не может вылезти livelock или ещё что-нибудь?

Что-нибудь всегда может "вылезти".

EP>Если требуется fault tolerance, не считая какие-то совсем тривиальные случаи, то придётся планировать аварийное завершение с освобождением всех ресурсов.

согласен. Но это другая тема.
И каждый день — без права на ошибку...
Re[33]: Deadlock-prevention алгоритм
От: landerhigh Пират  
Дата: 04.07.14 17:17
Оценка:
Здравствуйте, Lazin, Вы писали:

L>>Опасность дедлоков в том, что в теплице при тестировании они могут не вылезать. То есть может быть такое условие, но вылезает оно только после свистка членистоногово после непродолжитльных осадков жидкой формы в четвертый день недели. То есть неправильный порядок блокировки может никак себя не выдать даже с этой либой, что бы кто ни делал.


L>И решения у этой проблемы все равно нет.


Есть — планирование и геноцид, дискриминация, ковровые бомбардировки и обычновенный фашизм во время code review.

L>>Я вполне могу допустить валидные случаи, когда одни и те же пары мьютексов лочатся в разных порядках в одном и том же или разных тредах, но не вызывают дедлока, т.к. такое поведение является предусмотренным архитектурой. Будет честный false positive.


L>Ну я же явно оговариваю, что так делать нельзя. Так что здесь все ок.


Ну то есть использовать эту либу правильно все равно смогут только те, кто прекрасно понимает все тонкости многопоточного программирования и без того. остальные будут напоминать обезьяну с гранатой.
www.blinnov.com
Re[11]: Deadlock-prevention алгоритм
От: landerhigh Пират  
Дата: 04.07.14 17:19
Оценка:
Здравствуйте, B0FEE664, Вы писали:

SD>>Для этого потоки не нужны. Reactor-based model украдена задолго до нас. У вас классический пример сервера (просто взгляните на ваш "одноядерный ARM" как на сервер, клиентами которого выступают моторы и приборные панели).


BFE>Если бы у нас была реалтайм система, то так бы и пришлось делать. Да, сначала так и пытались, но оказалось, что это довольно сложный патерн в плане добавления в него новых событий: один loop должен знать о всех событиях системы, что оказалось очень неудобным, так как у нас несколько раз поменялись подключаемые устройства и их характеристики.


Какие проблемы предусмотреть соответствующее архитектурное решение? Оно ж простое как пробка.

BFE>PS Ходить по воде и разрабатывать программы, следуя спецификации, очень просто… если они заморожены.


This excuse is lame, bro.
www.blinnov.com
Re[31]: Deadlock-prevention алгоритм
От: Evgeny.Panasyuk Россия  
Дата: 04.07.14 18:40
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>>>>>Так что если пользоваться стандартом, то такие исключения надо обрабатывать.

EP>>>>Во-первых, какие-то специальные телодвижения не нужны (разве что поставить assert ) — там же в корне std::exception.
BFE>>>assert — это исключительно средство разработки. В дебаг версии на него можно вообще никогда не наткнуться.
EP>>1. По хорошему тесты и equivalence partitioning должны были запустить assert у которого существуют пути запуска. Этого конечно проще достичь когда низкоуровневый многопоточный код не раскидан по всей системе, а локализован в отдельном модуле.
BFE>Мне кажется или это высказывание равносильно предложению: давайте отловим все баги в системе?

Точнее: вместо раскидывания по всей системе, локализуем низкоуровневый многопоточный код в модуле, который легко протестировать/верифицировать.

EP>>2. При необходимости, assert'ы можно включить и в release'е (но нужно помнить о том, что некоторые проверки могут поменять postconditions, например алгоритмическую сложность). Видел подобные assert'ы в release в одной очень популярной программе, с сотнями миллионов установок.

BFE>Количество установок не говорит о качестве когда. Может оттого они и оставили assert'ы, что отладить не смогли.

Я ничего не говорил про качество кода, я всего лишь показал, что есть такая практика assert в release.

EP>>3. Необязательно использовать стандартный assert, например некоторые библиотеки специально используют собственный assert, чтобы дать пользователю больший контроль, например SGI STL.

BFE>Да и? А я вот видел, как предлагали assert в релизе заменить бросанием эксепшена.

Возможно и такое, но в целом, у assert и исключений разная семантика

BFE>Я же не про это говорю. Я говорю, что если есть код, который содержит в себе throw, то должен быть и catch, который его ловит даже если разработчик думает, что такое никогда не произойдёт. Если вы не собираетесь выкинуть ваш код, то будьте готовы, что завтра ваш код кто-то подправит и исключение, таки, будет брошено.


Это похоже на перевод темы с использования исключений при обнаружении deadlock'а, на использование исключений вообще.
Я же не против исключений в целом, и даже считаю что код должен быть к ним готов по-умолчанию.

EP>>Исключительные ситуации, в моём понимании, это внешние проблемы по отношению к коду, а не его внутренние баги. Например при десериализации структуры внезапно закончился файл — это же не баг кода, да? или например в знаменателях повылазили значения близкие к нулю из-за вырожденности системы, или входные данные в неправильном формате и т.д и т.п.


BFE>"в знаменателях повылазили значения близкие к нулю из-за вырожденности системы"

BFE>- разве это не баг в программе?

Если такие значения возникли не из-за ошибки программиста, а например из-за ошибочного ввода (но всё же ожидаемого) — то нет, не баг.

BFE>Если входные данные в неправильном формате приводят к состоянию deadlock'а, то это ошибка в программе?


Зависит от. Я изначально говорил, что ошибка — это незапланированный deadlock.
Например, если у тебя некоторый хитрый алгоритм, который дедлочится на неправильных входных данных, и такое поведение полностью ожидаемо (мол предотвращение этого deadlock'а совсем, било бы по производительности в happy-case) — то нет, не ошибка, а ожидаемое состояние, из которого можно выбраться — так как известно каким образом мы туда попали.
Или другой вариант — если пользователь осведомлён, что данные в неправильном формате могут всё поломать, и несёт за это полную ответственность — то тут даже откат из deadlock'а можно не предусматривать, ибо ССЗБ.

Это всё вопрос pre/post-conditions.
Например у std::vector есть .operator[] и .at. Внутри первого assert (в некоторых реализациях), а внутри второго исключение.

Но, опять таки, вариант с неким хитрым алгоритмом, который на одних данных дедлочится, а на других нет — это скорее исключение чем правило.
В то же время, например, можно элементарно придумать ситуацию, в которой плохие входные данные приведут к выходу за границы массива.
Re[31]: Deadlock-prevention алгоритм
От: Evgeny.Panasyuk Россия  
Дата: 04.07.14 19:36
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>>>А что можно сказать про незапланированный deadlock?

EP>>Это ошибка в коде
BFE>>>Всё. Висим. Точка. Речь о том, чтобы в принципе избежать такой ситуации.
EP>>Избежать deadlock'а или чего?
BFE>Т.е. вы считаете, что можно избежать всех deadlock'ов во всех возможных системах и исправить такие ошибки?

Нет, я так не считаю.
Выброс исключения прям перед deadlock'ом, в который неизвестно как попали — не гарантирует выход в какое-то стабильное состояние, более того — может привести к ещё большим потерям.
Если нужен нормальный fault tolerance, то всё-равно придётся планировать аварийное завершение.

EP>>Так мы же и так рассматриваем ситуацию, которой в корректной программе быть не должно. И соответственно раз произошёл deadlock, "то и не такое может произойти"

BFE>Качественный код должен корректно обрабатывать ошибочные ситуации, даже если этой ситуации "в корректной программе быть не должно".

Не вижу оснований для данного утверждения.
Например, у алгоритмов STL есть определённые preconditions, при нарушении которых всё может пойти в разнос, вплоть до расстрела памяти или зависания — тем не менее, некачественным кодом он от этого не становится.

Опять таки, если по характеру задачи нужен fault tolerance, то нужно принимать соответствующие меры, например watchdog, дублирование, вплоть до использования разных алгоритмов и т.д и т.п.
Но прежде всего, имхо, нужно иметь корректный, оттестированный и верифицированный код — от этого никуда не деться в любом случае, никакие свистульки тут не помогут.

EP>>>>или что ещё хуже — livelock.

BFE>>>livelock возможен, но и с ним понятно как бороться — отдавать время другим ниткам из той нитки, что deadlock обнаружила (после снятия всех блокировок). Если так действовать, то livelock возможен только при перегрузке системы.
EP>>Незапланированный deadlock возможен только в коде с багом, точно также как и livelock.
BFE>Не бывает сложных систем без ошибок.

Выброс исключения из совершенно неизвестного состояния, не только не решит это ошибку, но ещё и может всё усугубить.

BFE>DoS-атака возможна даже на сервер работающий без ошибок. Чем DoS не livelock?


DoS это скорее starvation.

EP>>Раз уж мы получили deadlock, то почему при раскрутке стэка не может вылезти livelock или ещё что-нибудь?

BFE>Что-нибудь всегда может "вылезти".

При незапланированном deadlock'е, как неоднократно замечали ранее, находишься в неизвестном состоянии. Если кинуть исключение, то есть некоторый шанс вернуться в известное и стабильное состояние. Если же прибить процесс и начать заново, то шанс возврата в стабильное состояние намного больше, да и к тому же для fault tolerance это всё-равно понадобиться.
Re[34]: Deadlock-prevention алгоритм
От: Lazin Россия http://evgeny-lazin.blogspot.com
Дата: 06.07.14 09:44
Оценка:
L>>И решения у этой проблемы все равно нет.
L>Есть — планирование и геноцид, дискриминация, ковровые бомбардировки и обычновенный фашизм во время code review.

Я не могу вынести это в библиотеку

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


Никто и не утверждал обратного.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.