ska onstat-Вы меня убедите, если подскажете как взвести 5 мутексов
одновременно, чтобы избежать дедлоков между процессами.
Я, к сожалению, простого способа не знаю.

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


Попробую.
t1, t2,t3 tn некие моменты времени

Некий процесс П1 устанавливает блокировку на ресурс А1,
но для работы с этим обьектом необходимо
установить блокировку еще на ресурс(обьект) А3.
Для работы с A3 необходимо поставить блокировку на А2.

Некий другой процесс устанавливает блокировку на ресурс A2
и ему тоже требуется работа с А3.

Третьему процессу П3 для нормальной работы достаточно блокировать
обьекты по одиночке.

т1 А1 заблокирован процессом П1.
т2 А2 заблокирован процессом П2.
т3.А3 заблокирован процессом П1.
т4 П1 ждет разблокировки ресурса А2.
т4 П2 ждет разблокировки А3.

Все ждут , никто ничего не делает.

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

To ALL: Как это зделать на мутексах?

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


Функционал аналогичный rwlock реализуется классом в 40 сторках кода.

ska
К тому же есть очч большие нюансы ежели имеете дело со всякими динозаврами. Проблема может заключаться в том что не все threadы лайтвейт :-)) pthread равно как и всякая жава проблему зту решает через симуляцию,

Чесно , Ничего не понял.
Что имеется ввиду под динозаврами?
Смысл threadы лайтвейт :-)) ?
Причем тут Жава?

Что такое симуляция?

ska
а вот изза одного semop-а все ваши потоки и подмерзнут...


Используя IPC_NOWAIT получаем механизм подобный try_lock.

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


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

AkhДа, кстати, как корректней id для семофоров выбирать. Т.к. он будет использоваться в разных программах, то задавать его прийдется статически. Может существуют каки-либо правила, или зарезервированные интервалы?


ф-я ftok генерирует ключи для IPC по имени файла и числу.
при вызове из разных программ, но с одинаковыми параметрами
ключи будут одинаковы.

Akh

Каким образом можно решить проблему тупиков?
..........



Спасибо, можно еще ссылку на первоисточник?

ska onstat-
Некий процесс П1 устанавливает блокировку на ресурс А1,
но для работы с этим обьектом необходимо
установить блокировку еще на ресурс(обьект) А3.
Для работы с A3 необходимо поставить блокировку на А2.
Некий другой процесс устанавливает блокировку на ресурс A2
и ему тоже требуется работа с А3.

Третьему процессу П3 для нормальной работы достаточно блокировать
обьекты по одиночке.

т1 А1 заблокирован процессом П1.
т2 А2 заблокирован процессом П2.
т3.А3 заблокирован процессом П1.
т4 П1 ждет разблокировки ресурса А2.
т4 П2 ждет разблокировки А3.
Все ждут , никто ничего не делает.



Если "функция" блокировки А1 будет блокировать сначала А3 (вызывать функцию) а та в свою очередь А1 то никаких дедлоков не будет.
Хуже конечно когда есть круговая зависимость.


Вот и получается круговая зависимость.

ska
onstat-
При правильном использовании массивов семафоров все необходимые обьекты блокируются за одну операцию и в один момент веремни.


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


При любой синхронизации можно насупить комуто или самому себе на хвост :)

К семафорам нужно относится не как к блокировкам в чистом виде а как
к флагам(приоритетам) синхронизации.

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

По сравнению с pthread экономия как минимум на 5 системных вызовах.

Семафор не только защищает данные, а и управляет приритетами выполнения.


ska
Ну например завести один мутекс, один кондишн и массив int - полностью просимулирует семафоры.


Массив семафоров так просто проэмулировать не получится.
1. Не всегда есть необходимость менять(проверять) все семафоры в наборе, а только некотрые.
2. Заставить нить заснуть по кондишину зависящему от 1 до n элементов массива?
3. Гораздо проблематичнее ее потом будить по кондишину.

Теоретически реализовать можно, но это будет не просто.

ska
Ну посмотрите хоть на java хоть в .NET - послабее чем pthread но хватает для всего. А с точки зрения широты употребления и полезности знаний pthread уж явно лучче чем IPCS.

Сергей

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

С уважением, Константин