man pthread_mutex*

Перехват системных вызовов в OS Linux

>man pthread_mutex*

И как это использовать в _межпроцессном_ взаимодействии ? ;)

IPC 

это 
- сообщения
- семафоры
- шареная память
(man ipc)

по идее поведение мутекса можно изобразить с помощью семафора

man semget
man semop
man semctl

Кто-нибудь может много что сказать.
Ты сначала вопрос задай.

По стандарту POSIX можно использовать, надо только установить специальный аттрибут у мьютекса или условной переменной, и разместить ее в разделяемой памяти. Но это пака еще мало переносимо.

Вдогон: Перехват системных вызовов в OS Linux

>По стандарту POSIX можно использовать, надо только установить специальный аттрибут у мьютекса или условной переменной, и разместить ее в разделяемой памяти. Но это пака еще мало переносимо.

И как это будет выглядеть ?

Именованный раздел памяти + POSIX семафоры.

Семафоров существует фигова туча: SYSV, OSF, POSIX.
man sem_init
может выдать информацию о командах POSIX семафоров.
С переносимостью пока хреново.
man sem_open
может даже ничего и не выдать.
Рекомендую проверить не написано ли что-либо типа
LinuxThreads currently does not support process-shared semaphores,
thus sem_init always returns with error ENOSYS if pshared
is not zero.
в man-ах имеющейся ревизии.
SYSV можно использовать однозначно.
Пример можно найти в форуме парой строчек ниже с названием "семафоры".
Выбрасываем инициализацию второго семафора, все семафоры заменяем
на один и получаем пример (если скомпилируется :-).
Ну может права еще придется подправить.

Специальное добавление для зануд :-) :
1. В строке с "фигова" забыл "и т.п."
2. Писано для линуксоидов. Любители VxWorks сами знают как
должны работать нормальные mutex с обработкой владельца,
реверсом приоритета и т.п.

>Любители VxWorks сами знают как должны работать нормальные mutex с обработкой владельца, реверсом приоритета и т.п.

А причем тут VxWorks? Как работают "нормальные" мьютексы с обработкой владельца и наследованием/защитой (не обращением! :) приоритетов описано в открытом SuS.

Кроме того, большинству программистов и не нужно знать как устроены мьютексы, а большинству программистов не-RTOS необязательно знать и о существовании механизмов борьбы с обращением приоритетов (впрочем, по этому поводу был большой флейм на zdnet).

Для начала хотя бы нужно освоить технологии zero-copy, а потом уже всякую фигню вроде особенностей мьютексов. ;)

Вот как легко расшевелить зануд :-)
А я то думал разбужу или нет? :-)
Ну, любят использовать именно английское слово реверс
(вот уж не помню сколько лет) в описании.
Уж слишком хорошо отражает характер поведения в некоторых ситуациях.
И одно дела читать (уже радует), а другое использовать.

К продолжению нашего диалога об atomic:

On processors supporting atomic compare-and-swap (Intel
486, Pentium and later, Alpha, PowerPC, MIPS II, Motorola
68k), the sem_post function is async-signal safe and can
therefore be called from signal handlers.

On the Intel 386 and the Sparc, the current LinuxThreads
implementation of sem_post is not async-signal safe by
lack of the required atomic operations.

Предлагаю начинать список процессоров с 486. Идет?
А то некоторые зануды сигналами бросаются по поводу и без повода.
А те иногда просто плохо compatible с жизнью.

io:

>Уж слишком хорошо отражает характер поведения в некоторых ситуациях.
>И одно дела читать (уже радует), а другое использовать.

На не-RTOS (timesharing OS, как правило) это всё не имеет смысла. Процессор никогда не простаивает, когда есть готовые к исполнению задания, а время отклика никто не гарантирует. Простаивание высокоприоритетной нити при обращении приоритетов не является какой-то проблемой scheduling... это является следствием того, что она согласилась синхронизироваться с другой нитью.

По поводу atomic: читайте про алгоритм Деккера... хотя что про него читать - он и так интуитивно ясен.

По поводу сигналов: как было написать код - мое личное дело ;) мне так было проще и короче. Там есть один небольшой race (между while и pause), но он легко закрывается.

успехов.

Ну по поводу "не имеет смыcла" и "не гарантирует" это отдельный вопрос. По поводу "проще" сомнения. Скорее "по другому ... обломись".
Но я не буду уподобляться другим Вашим оппонентам, хотя
сегодня препод из МИФИ оценил эту программу хорошо: "Так прос... на
сигналах? Гений!"

Вы мне батенька лучше байку про "технологии zero-copy" раскажите.
zero-copy часто встречается. Технология вместе реже.
Как сказал хихикая классный переводчик тех. литературы: "переливание
из пустого в порожнее". Правда он уже массу лет говорит "английского
не знаю", но за классность имеет очень хорошо. С такими это бывает.
За переливание уже платят? Где учат?

>Ну по поводу "не имеет смыcла" и "не гарантирует" это
>отдельный вопрос. По поводу "проще" сомнения. Скорее "по
>другому ... обломись".

О да Вы скорость научились определять - что скорее, а что медленнее ... Разность между эффективностью использования семафора и сигнала в данном случае - константа, так что роли не играет. Код же короче и задержка (в случае Linux для моего варианта) меньше.

>Но я не буду уподобляться другим Вашим оппонентам, хотя
>сегодня препод из МИФИ оценил эту программу хорошо: "Так
>прос... на сигналах? Гений!"

А какие-нибудь аргументы Ваш дружок из Вашего мухосранского института привел? Или просто воздух попортил?

В коде есть race, о котором я выше написал , устраняется путем добавления одного вызова sigprocmask в начале и sigsuspend вместо pause.

Кстати, такого рода фразы довольно характерны для младших преподавателей деревенских ВУЗов - понтить уже умеют, а как начнут аргументировать - так все студенты смеются.

Ну пускай попускает сопли - может ему радость от этого какая ... ;) Наверное от большого ума остался там преподавать ...

>Технология вместе реже.

Что значит "вместе"?

>С такими это бывает. За переливание уже платят? Где учат?
Вам виднее ;)

Судя по примеру с физикой не было не только "деревенских ВУЗов",
но даже школа закончена с трудом. Это какие же должны
быть преподы, чтобы тривиальный факт не вбить?
Нет, наверно преподы не виноваты. Проблемы с обучаемостью.
Судя по устаревшим ссылкам давно :-(

Предлагаю тему закрыть. А то такое наговорим зря.

А преподов жалко, некоторым за то, что остались здесь,
памятник ставить надо.

>Судя по примеру с физикой не было не только "деревенских ВУЗов", >но даже школа закончена с трудом. Кстати, да - cудя по Вашему примеру с физикой учились Вы там не 11 годков, а поболе (а может и сейчас продолжаете).

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

Ну благо я написал решение с комментариями.

P.S. В общем, всё с Вами понятно.

Данное решение в Вашем исполнении мне понравилось больше всего:

>print("%s", str[i]); >:))))))))))))))))

Информативно! Впрочем, из того же источника:
"Умный человек разберется"

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

Всем Спасибо. Кажется начало прояснятся.

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

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

Истинно царский комментарий. Уважаю.

Вы уж извините мы тут с Murr-ом слегка пошалили в Вашей дискуссии.
Он всегда предлагает shared memory.
Но вот доказать мне эффективность для переброски данных не может
(см. дискуссию на предыдущей странице). Достаточно в его
собственном примере поделить размер буфера на 8 (с увеличением,
естественно, количества пакетов) и трубки обгонят разделяемую память.
Стоило ли ему губить молодость на ВМиК?
Вот и приходится говорить: "Не верю".

Ясно, что разделяемую память можно всегда использовать для
организации мьютексов. OSF семафоры, например, тоже именно
так работают. Только вопрос об эффективности может возникнуть.
Если использовать, например, "в чистом виде" агоритмы,
которые предлагает Murr (предназначены исключительно для ядер
многопроцессорных систем), то производительность может и слегка
гуд бай (сильных потерь ожидать трудно).
Ну, а ежели думать, то должна быть и пристойная реализация.

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