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

Некий такой прокси с промежуточной обработкой и хитрой маршрутизацией .

Нити между собой спят на мутексах либо на ожидании из сокетов ( epoll),
иногда налетают на дедлоки или продолжают спать когда нужно работать.

Какие есть варианты алгоритмов реализации сна
нитей при бездействии, без использования явного sleep
и пустых перепрыгиваний с мутекса в epoll и обратно
для проверки информации в сокетах?

Ссылки приветсвуются.

kealon(Ruslan)д0k,

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

Для меня нити и потоки синонимы.
Приложение использует вытесняющую многозадачность ОС
и POSIX Threads.

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

Едиственный вариант, который пока я вижу, выбросить epoll
и написать велосипед , который по sigio
будет сбивать потоки( нити ) с мутексов( семафоров).
То есть потоки должны спать только на мутексах(семафорах) и никогда на сокетах.

lockedд0kпропущено...


Для меня нити и потоки синонимы.
Приложение использует вытесняющую многозадачность ОС
и POSIX Threads.

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

Едиственный вариант, который пока я вижу, выбросить epoll
и написать велосипед , который по sigio
будет сбивать потоки( нити ) с мутексов( семафоров).
То есть потоки должны спать только на мутексах(семафорах) и никогда на сокетах.
сажаешь один поток на epoll а остальные на condition_variable в качестве рабочих потоков. И нет никаких дэдлоков.

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

kealon(Ruslan)д0k,

значит всё же потоки, а не нити - у нити нет своего выделённого времени выполнения

по вопросу: как вариант можно свести всё к сокетам - т.е. создать управляющее соединение к самому себе вместо семафора

Управляющее соединение рассматриваем.
http://man7.org/linux/man-pages/man7/mq_overview.7.htmlно не через сетевые сокеты

lockedд0кпропущено...


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

На уровне управления проектом распределено.
Что отраpазилось на API.
Люди , которые занимаются системными
вопросами не лезут в исходники где реализована бизнеслогика,
а те кто сконцентрирован на бизнеслогике не лезет в системщину.
Фронтэнд сконцентрирован только на эргономике и удобстве интерфейса.

Рамках пока свободного квеста смотрим на слабые места системы.
Планируем заглянуть в нишу жеского хайлоад.

Завтра распродажи на алиэкспересе покажут
новые места для на которые нужно будет обращать внимание.

kealon(Ruslan)д0k,

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

Огромное Спасибо!!!
Это приблизительно то, что нам нужно.