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

Почему-то это не остановило разработчиков kqueue/epoll. Может "характеристики подключаемых устройств" ничуть не хуже впишутся в стандартную модель open/read/write/close/ioctl?

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

Возможно, я невнимательно читал весь тред, но — вы не могли бы еще раз написать, используется ли в вашем продуте какая-то ОС? Или всё полностью самописное, включая потоки?

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

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

О качестве кода тут говорит то, как часто из этих миллионов установок assert'ы таки проваливались

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

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

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

Было бы неплохо... но не в этой вселенной, к сожалению

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

L>Никто и не утверждал обратного.

Ну, лично для меня полезность изобретения в данном случае не очень понятна.
Хотя, если на ее основе сделать библиотеку для юнит-тестирования, которая подменяет примитивы синхронизации и выявляет все места, в которых порядок синхронизации нарушен, то можно было бы получить неплохую тулзу для возюканья нерадивых программеров мордой по асфальту.
Правда, опять же есть риск эпидемии простреленных конечностей, вызванных тем самым "нам над архитектурой думать не надо, у нас есть супер-пупер-либа"

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

L>Есть — планирование и геноцид, дискриминация, ковровые бомбардировки и обычновенный фашизм во время code review.
Это не даёт никаких гарантий, к сожалению.
Кроме того есть ещё такой аспект, как стоимость разработки против стоимости эксплуатации...

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


L>>Есть — планирование и геноцид, дискриминация, ковровые бомбардировки и обычновенный фашизм во время code review.
E>Это не даёт никаких гарантий, к сожалению.

А полные гарантии в этом мире вообще только в одном месте возможны.

E>Кроме того есть ещё такой аспект, как стоимость разработки против стоимости эксплуатации...

Естетственно. А еще есть стоимость поддержки и дальнейшего развития. А также есть потерянные для сбыта направления.

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

EP>Точнее: вместо раскидывания по всей системе, локализуем низкоуровневый многопоточный код в модуле, который легко протестировать/верифицировать.
Далеко не всегда можно локализовать многопоточный код в отдельном модуле. Скорее наоборот, обычной является ситуация, когда взаимодействие отдельных модулей является синхронизацией потоков.
И почему, кстати, взаимодействие потоков вы называете низкоуровневым кодом?

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

EP>В то же время, например, можно элементарно придумать ситуацию, в которой плохие входные данные приведут к выходу за границы массива.
С таким подходом я согласиться никак не могу.

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

BFE>>Да, сначала так и пытались, но оказалось, что это довольно сложный патерн в плане добавления в него новых событий: один loop должен знать о всех событиях системы, что оказалось очень неудобным, так как у нас несколько раз поменялись подключаемые устройства и их характеристики.
SD>Почему-то это не остановило разработчиков kqueue/epoll. Может "характеристики подключаемых устройств" ничуть не хуже впишутся в стандартную модель open/read/write/close/ioctl?
Это задачи разного масштаба и требований.

BFE>>Программа должна работать в разных конфигурациях оборудования. Оказалось проще под каждое устройство написать свой программный модуль со своими циклами обработки данных, чем иметь один динамический изменяемый event loop.
SD>Возможно, я невнимательно читал весь тред, но — вы не могли бы еще раз написать, используется ли в вашем продуте какая-то ОС? Или всё полностью самописное, включая потоки?
Debian.

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

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

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

EP>>>Так мы же и так рассматриваем ситуацию, которой в корректной программе быть не должно. И соответственно раз произошёл deadlock, "то и не такое может произойти"
BFE>>Качественный код должен корректно обрабатывать ошибочные ситуации, даже если этой ситуации "в корректной программе быть не должно".
EP>Не вижу оснований для данного утверждения.
EP>Например, у алгоритмов STL есть определённые preconditions, при нарушении которых всё может пойти в разнос, вплоть до расстрела памяти или зависания — тем не менее, некачественным кодом он от этого не становится.
Согласен. Но речь не об этом. Программист должен обеспечить preconditions. Но если STL функция может бросить исключение, то обработка такой возможности должна быть предусмотрена.

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

BFE>>Не бывает сложных систем без ошибок.
EP>Выброс исключения из совершенно неизвестного состояния, не только не решит это ошибку, но ещё и может всё усугубить.
Тем не менее это обычное дело: верхний уровень поймавший исключение очень мало знает о том, что "там в низу" случилось.

EP>При незапланированном deadlock'е, как неоднократно замечали ранее, находишься в неизвестном состоянии. Если кинуть исключение, то есть некоторый шанс вернуться в известное и стабильное состояние. Если же прибить процесс и начать заново, то шанс возврата в стабильное состояние намного больше, да и к тому же для fault tolerance это всё-равно понадобиться.
Расскажите мне, почему шанс возврата в стабильное состояние намного больше? Я не вижу причин для этого. При поимке исключения у нас есть хоть какая-то информация, когда же убивается процесс, то даже такой информации нет.

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

EP>>Точнее: вместо раскидывания по всей системе, локализуем низкоуровневый многопоточный код в модуле, который легко протестировать/верифицировать.
BFE>Далеко не всегда можно локализовать многопоточный код в отдельном модуле. Скорее наоборот, обычной является ситуация, когда взаимодействие отдельных модулей является синхронизацией потоков.
BFE>И почему, кстати, взаимодействие потоков вы называете низкоуровневым кодом?

Не взаимодействие потоков, а использование низкоуровневых примитивов типа mutex, condition_variable, atomic, etc.

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

Проверил на значение близкое к нулю и выбросил исключение, об этом и речь выше. (иногда дешевле делать проверки в ходе вычислений, а не сразу при получении данных, но это другой вопрос)

EP>>Но, опять таки, вариант с неким хитрым алгоритмом, который на одних данных дедлочится, а на других нет — это скорее исключение чем правило.
EP>>В то же время, например, можно элементарно придумать ситуацию, в которой плохие входные данные приведут к выходу за границы массива.
BFE>С таким подходом я согласиться никак не могу.

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

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

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

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

BFE>>>Качественный код должен корректно обрабатывать ошибочные ситуации, даже если этой ситуации "в корректной программе быть не должно".
EP>>Не вижу оснований для данного утверждения.
EP>>Например, у алгоритмов STL есть определённые preconditions, при нарушении которых всё может пойти в разнос, вплоть до расстрела памяти или зависания — тем не менее, некачественным кодом он от этого не становится.
BFE>Согласен. Но речь не об этом. Программист должен обеспечить preconditions.

Верно.

BFE>Но если STL функция может бросить исключение, то обработка такой возможности должна быть предусмотрена.

Если STL функция может обнаружить нарушение preconditions, то лучше всего это assertion, и именно так поступают многие реализации.
А те состояния, которые приводят к исключениям, входят в preconditions. И, соответственно, выброс исключения — это вполне легальный postcondition.

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

Может в некоторых случаях, но не обязано в общем.

BFE>>>Не бывает сложных систем без ошибок.
EP>>Выброс исключения из совершенно неизвестного состояния, не только не решит это ошибку, но ещё и может всё усугубить.
BFE>Тем не менее это обычное дело: верхний уровень поймавший исключение очень мало знает о том, что "там в низу" случилось.

Речь-то как раз о том, что исключение вылетевшее из неизвестного состояния далеко не факт что вообще сможет дойти до обработчика на верхнем уровне.

EP>>При незапланированном deadlock'е, как неоднократно замечали ранее, находишься в неизвестном состоянии. Если кинуть исключение, то есть некоторый шанс вернуться в известное и стабильное состояние. Если же прибить процесс и начать заново, то шанс возврата в стабильное состояние намного больше, да и к тому же для fault tolerance это всё-равно понадобиться.
BFE>Расскажите мне, почему шанс возврата в стабильное состояние намного больше? Я не вижу причин для этого.

Шанс успешного прибития процесса (находящегося в неизвестном состоянии) намного выше шанса того, что исключение (вылетевшее неизвестно откуда и как) доберётся до обработчика и ничего не сломает по пути.

BFE>При поимке исключения у нас есть хоть какая-то информация, когда же убивается процесс, то даже такой информации нет.

По поводу наличия информации ситуация практически одинаковая — и при выбросе исключения и при terminate/kill можно собрать всё необходимое.

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

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

S>Ещё вот такая штука — не лучше ли при расчёте хэшей завязываться на sizeof? Т.е. сейчас хэш по адресу считается с шагом адреса в 64 байта. Допустим у нас размер наиболее часто блокируемых объектов 128 байт, причем аллокируются объекты на страницах с выравниванием не меньше чем 128 байт. Т.о. из всего набора мьютексов для них будет использоваться только половина. При размере 256 байт будет использоваться только четверть мьютексов, ну и так далее.

S>Такой хэш будет давать лучшее распределение блокировок:
S>

S>        //! Simple hash - simply returns it's argument
S>        struct SimpleHash {
S>            template<typename T>
S>            size_t operator() (const T* value) const {
S>                return reinterpret_cast<size_t>(value)/sizeof(T);
S>            }
S>        };
S>

Мне не нравится здесь деление. Если размер объекта меньше 64х байт — то объекты, расположенные внутри одной кэш линии будут хэшироваться на разные мьютексы, что имеет мало смысла. К тому же, деление — довольно медленная операция и не факт, что компилятор сможет оптимизировать его для всех размеров. Возможно, имеет смысл считать какой-нибудь более сложный хэш от указателя, а не просто накладывать маску.

BFE>Debian.

Т.е. у вас УЖЕ БЫЛ механизм epoll, и всё, что вам требовалось — реализовать драйвер мотора/экрана? Чтобы иметь /dev/engine1, /dev/screen1. И дальше пользовать системный epoll.

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

BFE>Т.е. вы пишите программы, которые не бросают исключений?

Дедлок — не исключение.

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

BFE>>Debian.
SD>Т.е. у вас УЖЕ БЫЛ механизм epoll, и всё, что вам требовалось — реализовать драйвер мотора/экрана? Чтобы иметь /dev/engine1, /dev/screen1. И дальше пользовать системный epoll.
Это сейчас Debian, а подключили меня к проекту, когда использовали какую-то старую версию Linux собранную весьма специфическим образом.
И я подозреваю, что при использовании epoll придётся часть работы перекладывать на драйвера, которые придётся писать под каждое из устройств... и это при том, что можно обойтись стандартными средствами.
Кстати, если использовать epoll, то как там с timer событиями? Если запустить два timerfd_settime на 10 ms и на 17 ms, то они нормально работают? Интерференции не будет?
Ну и потом, сама идея, обрабатывать все события в одном цикле мне кажется неверным подходом: никакой модульности, всё монолитное

BFE>Это сейчас Debian, а подключили меня к проекту, когда использовали какую-то старую версию Linux собранную весьма специфическим образом.

epoll в ядре Linux появился где-то в 2003 году. Неужто настолько старую версию у вас использовали?

BFE>И я подозреваю, что при использовании epoll придётся часть работы перекладывать на драйвера, которые придётся писать под каждое из устройств... и это при том, что можно обойтись стандартными средствами.

Не распарсил. Что за "стандартные средства" и драйвера? Сейчас вы как со своими моторами общаетесь? Случаем, не через файловые дескрипторы?

BFE>Кстати, если использовать epoll, то как там с timer событиями? Если запустить два timerfd_settime на 10 ms и на 17 ms, то они нормально работают?

Отлично они работают. Хоть сто таймеров запускай. Современные ядра вообще чудесны и почти realtime — уж всяко лучше home made изделий. Всего-то нужно mlockall(MCL_CURRENT | MCL_FUTURE) для памяти да sched_setscheduler(0, SCHED_FIFO, ...) с нужным уровнем приоритета. Джиттер в пределах 2-3 микросекунд при умеренной загрузке процессора. Если принять еще некоторые меры, у меня получалось добиться 1 мкс. (но без гарантий).

BFE>Ну и потом, сама идея, обрабатывать все события в одном цикле мне кажется неверным подходом: никакой модульности, всё монолитное

Давайте конкретнее. Что значит "никакой модульности"? Кто мешает сделать модуль "мотор типа ZZZ"? Который из зависимостей будет тянуть только интерфейс вашей обёртки над epoll. Что тут "монолитного"? А ваш существующий код, думаете, менее монолитен? Тогда откуда дедлоки?

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

BFE>А разве не является первейшей задачей программиста проверить вводимые значения на валидность?
Это не всегда просто и не всегда быстро.
Скажем обрабатываем мы какой-то очень большой файл в несколько потоков, на какой-то момент концы не сошлись с концами. Что делаем?

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

BFE>Расскажите мне, почему шанс возврата в стабильное состояние намного больше? Я не вижу причин для этого. При поимке исключения у нас есть хоть какая-то информация, когда же убивается процесс, то даже такой информации нет.

Мало того, когда мы кидаем и ловим исключение, мы можем дать таки какие-то гарантии на целостность данных.
А если грубо убиваем процесс, то вообще никаких гарантий дать не можем. Даже того, что внутри-программные кэши все сбросились на диск

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

EP>Речь-то как раз о том, что исключение вылетевшее из неизвестного состояния далеко не факт что вообще сможет дойти до обработчика на верхнем уровне.

EP>Шанс успешного прибития процесса (находящегося в неизвестном состоянии) намного выше шанса того, что исключение (вылетевшее неизвестно откуда и как) доберётся до обработчика и ничего не сломает по пути.

Это очень зависит от стратегии использования исключений и обработки ошибок в программе...

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

BFE>>Это сейчас Debian, а подключили меня к проекту, когда использовали какую-то старую версию Linux собранную весьма специфическим образом.
SD>epoll в ядре Linux появился где-то в 2003 году. Неужто настолько старую версию у вас использовали?

Была какая-то странная сборка. Может там и был epoll, но вот даже стандартных средств доступа к последовательным портам не было.

BFE>>И я подозреваю, что при использовании epoll придётся часть работы перекладывать на драйвера, которые придётся писать под каждое из устройств... и это при том, что можно обойтись стандартными средствами.
SD>Не распарсил. Что за "стандартные средства" и драйвера? Сейчас вы как со своими моторами общаетесь? Случаем, не через файловые дескрипторы?
Да, как обычно: open, cfsetospeed, poll, write...

BFE>>Ну и потом, сама идея, обрабатывать все события в одном цикле мне кажется неверным подходом: никакой модульности, всё монолитное
SD>Давайте конкретнее. Что значит "никакой модульности"?

Ну, например. Для работы с сетью мы используем стороннюю библиотеку с callback'ами и функцией ожидания. Как предлагаете подключить её к epoll?

SD>Кто мешает сделать модуль "мотор типа ZZZ"? Который из зависимостей будет тянуть только интерфейс вашей обёртки над epoll. Что тут "монолитного"?
Эээ... Может я чего-то не понимаю? Когда вы говорите об epoll, то сколько ниток исполнения вы предполагаете?

SD>А ваш существующий код, думаете, менее монолитен?
Да. У нас 15 независимых библиотек.

SD> Тогда откуда дедлоки?
Но у нас нет deadlock'ов.

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

EP>>>Точнее: вместо раскидывания по всей системе, локализуем низкоуровневый многопоточный код в модуле, который легко протестировать/верифицировать.
BFE>>Далеко не всегда можно локализовать многопоточный код в отдельном модуле. Скорее наоборот, обычной является ситуация, когда взаимодействие отдельных модулей является синхронизацией потоков.
BFE>>И почему, кстати, взаимодействие потоков вы называете низкоуровневым кодом?
EP>Не взаимодействие потоков, а использование низкоуровневых примитивов типа mutex, condition_variable, atomic, etc.

ok. Допустим. Расшифруйте подробнее, что значит "локализуем низкоуровневый многопоточный код в модуле"? Запуск всех ниток программы должен происходить в одном модуле?

EP>Проверил на значение близкое к нулю и выбросил исключение, об этом и речь выше. (иногда дешевле делать проверки в ходе вычислений, а не сразу при получении данных, но это другой вопрос)
ok. А почему взаимодействия потоков не попадают под эту концепцию?

EP>>>В то же время, например, можно элементарно придумать ситуацию, в которой плохие входные данные приведут к выходу за границы массива.
BFE>>С таким подходом я согласиться никак не могу.
EP>С каким подходом?
Когда входные данные позволяют обратится по адресам за пределами массива.

EP>Вполне жизненный пример выхода за границы массива из-за плохих данных: в начале файла идут значения некоторых узлов, а в конце ссылки на них в виде индексов, неправильный индекс может выйти за границы массива.
Если нет проверки в момент обращения по индексу, то вас ожидают проблемы поддержки.

EP>Теперь можно пример хитрого алгоритма, который дедлочится на плохих данных?
Нет в этом ничего хитрого. Из практики. Программа занимается корректированием пары изображений. Пользователь задаёт списки файлов на обработку. Если пользователь в одной обработке задаёт пару file1.tif file2.tif, а в другой file2.tif file1.tif, то иногда два потока блокируют друг друга: каждый из потоков открывает первый список из файла, а второй открыть не может, так как он открыт другим потоком. Дальше всё зависит от обработки такой ситуации, если первый файл остаётся открытым...