Нигде не встречал, но обнаружил что буфер pipe в ядре 2.6.9 два килобайта.

А как с fifo, кто-нибудь в курсе?

Ну, для пипе 2К это еще нормально, можно указатели передовать, но для fifo маловато будет. 2К для межпроцесового взаимодействия это даже не размер.

Sandro_KВообще когда мне приходилось в fifo писать достаточно большой объем данных у меня возникло много довольно проблем.

Что тогда использовал вместо fifo?

RanckontИспользуй программу, которая будет активно читать из пайпа в какой-нибудь другую память

У меня будет несколько клиентов отсылающих данные, а на приеме простые ворота к базе данных. На этой же машине уже две программы с 12 и 5-ю потоками со слипами не более 1ms. Так что ищу решение, чтобы не городит огород и не плодить потоки.

onstat- Akh Sandro_KВообще когда мне приходилось в fifo писать достаточно большой объем данных у меня возникло много довольно проблем.
Что тогда использовал вместо fifo?

Можно пробовать отправлять сообщения.
почитай man msgget, msgctl, msgrcv, msgsnd.

Там размеры регулируются параметрами ядра, но они тоже не безграничны.
(MSGMAX MSGMNB )


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

onstat-
man msgsnd
The followings are system limits affecting a msgsnd system call:
MSGMAX Maximum size for a message text: the implementation set
this value to 8192 bytes.

MSGMNB Default maximum size in bytes of a message queue: 16384
bytes. The super-user can increase the size of a message
queue beyond MSGMNB by a msgctl system call.

The implementation has no intrinsic limits for the system wide maximum
number of message headers (MSGTQL) and for the system wide maximum
size in bytes of the message pool (MSGPOOL).


ps Насколько я помню из других топиков прога пишется под Linux.
Если программа работает не от рута, параметры ядра можно поменять
глобально по системе через /etc/sysctl.conf раз и навсегда и даже на лету.

pss Еще подумай о передаче через разделяемую память.
Работать должно быстрее и с ограничениями на обьем попроще.

linux, linux.

Наверное при создании очереди буду устанавливать ее длину в msg_qbytes.
Через разделяемую память боюсь из-за синхранизации (процессы, передающие данные, в разных программах).

onstat-
Бояться тут нечего.

ИХМО Самое короткое и доходчивое описание правил синхронизации:


Межпрограммный мьютекс? Спасибо врубился. Ничего сложного.
Тогда второй вопрос, какие средства используются для разделяемой памяти? :)

Akh onstat-
Бояться тут нечего.

ИХМО Самое короткое и доходчивое описание правил синхронизации:


Межпрограммный мьютекс? Спасибо врубился. Ничего сложного.
Тогда второй вопрос, какие средства используются для разделяемой памяти? :)

Все сам нашел тамже. shmget, ... .

onstat-, Пасибо, не знал. Буду пробовать, надеюсь, что понравится.

onstat- Akh onstat-
Бояться тут нечего.

ИХМО Самое короткое и доходчивое описание правил синхронизации:


Межпрограммный мьютекс? Спасибо врубился. Ничего сложного.
Тогда второй вопрос, какие средства используются для разделяемой памяти? :)

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

Для абсолютно точной синхронизациив все это(и изменение и проверку) обязательно нужно делать за один вызов semop.
Иначе можно получить большой геморой.

Как я понимаю, самый простой способ, это установить симофор в единичку и вызывать в semop с -1, со сброшеным NOWAIT и установленным UNDO. А уже сложнее случаи представить сложно. И, как мне кажется, программирование семафороми - увлекательное занятие. :)

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

onstat- Akh
Хотя, вообще-то, тут, наверное, те же дедлоки, что и мьютексов, так что надо использовать либо, как ты подметил, целыми массивами, или расставлять логические приоритеты симофоров.

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

Ниже следующее я имел ввиду (т.е. иерархия):

Каким образом можно решить проблему тупиков?
Во-первых, можно использовать подход, основанный на применении иерархии mutex'ов. При этом подходе мы устанавливаем некое отношение старшинства между всеми mutex'ами в нашей программе, и в любой ситуации, когда нам необходимо захватить несколько mutex'ов одновременно, мы захватываем строго по старшинству, то есть сначала самый старший, потом mutex который младше первого, но старше остальных и т.п. Если строго соблюдать это правило то тупиков не возникнет. Оставляя в стороне формальное доказательство этого факта, рассмотрим, как действует этот подход, на нашем примере с двумя mutex'ами и двумя нитями. Согласно правилу обе нити должны будут захватывать сначала mutex A, и только потом B, ясно, что тогда тупиковой ситуации не возникнет, так как после того как первая нить захватит первый mutex, второй либо будет свободен [если вторая нить нуждается в обоих mutex'ах, то она остановится на захвате первого], либо будет захвачен, но на конечный отрезок времени / в случае если вторая нить хочет работать только со вторым mutex'ом, то ничто не помешает ей его захватить, но тупика не возникнет, так как она не имеет права пытаться захватить первый, и, следовательно, обязана освободить захваченный mutex в течение конечного периода времени /.

Стоит заметить, что часто не надо устанавливать отношения иерархии между всеми mutex'ами, так, например, если логика программы нам гарантирует что два mutex'а никогда не будет захватываться последовательно одной нитью, то нас не интересует отношение старшинства меду ними / иногда его можно вывести на основании правила транзитивности из отношений старшинства между этими и другими mutex'ами, а иногда и нельзя /.

Может возникнуть вопрос - а как именно устанавливать это самое отношение старшинства? Часто это отношение обусловлено самой структурой данных, которые защищают mutex'ы. Например, очевидно, что если мы имеем контейнер, который защищен mutex'ом и который содержит объекты каждый из которых сам защищен mutex'ом, то логично сначала захватывать mutex контейнера, а потом mutex объекта / при этом mutex контейнера можно освободить, дав другим нитям возможность работать с другими объектами в данном контейнере /. В случае если мы не можем просто задать иерархию опираясь на свойства данных, например, если мы имеем некоторое неизвестное заранее количество динамически создаваемых объектов, то можно воспользоваться следующим искусственным приемом для наведения иерархии. Этот прием заключается в том что мы определяем что первый mutex старше второго, если абсолютное значение адреса первого mutex'а больше соответствующего значения для второго [а можно использовать адреса защищаемых объектов или более того ввести нумерацию выдавая последовательный номер для каждого mutex'а при его инициализации]. Замечу что в реальных приложениях мы скорее всего будем использовать некую комбинацию этих двух подходов установления отношения старшинства.

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

В этих случаях имеет смысл использовать второй подход к предотвращению тупиков. Он основывается на использовании неблокирующего варианта операции захвата mutex'а, то есть pthread_mutex_trylock и называется "попытка и откат" / try and back-off /. Идея этого подхода очень проста: мы можем захватываем mutex'ы в произвольном порядке, но используем при этом операцию pthread_mutex_trylock, если эта операция в некоторый момент нам возвращает EBUSY / то есть если один из mutex'ов который мы пытаемся захватить уже захвачен /, то мы освобождаем все захваченные mutex'ы, как бы уступая дорогу нашему конкуренту. Ясно, что при таком подходе тупиков не возникает, с другой стороны сразу виден основной недостаток этого метода, а именно дополнительные накладные расходы, которые появляются из-за многократных попыток захвата и многократного освобождения mutex'ов. Кроме того, легко себе представить ситуацию, когда две нити пытаются захватить один и тот же набор mutex'ов A и B, но в разном порядке, и при этом ни одна из них не может сделать этого, так как все время натыкается на соперничающую нить / несмотря на то, что та регулярно освобождает свой mutex /. То есть нет теоретической гарантии работы схемы. Практически же в ситуациях, когда конкуренция за ресурсы не высока, данный подход работает вполне эффективно и надежно.

onstat-
Немного не так,

Вот пример
который я разбирал, и который мне очень сильно помог в понимании
процесса.


Даже с первого взгляда видно, что хороший пример. Спасибо.

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

onstat- Akh

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



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

вроде, отсюда

ska
Да нет смысла спорить. Есть задачи для которых semop намного эффективнее и удобнее. Сам его активно пользовал. А лет 20 назад ничего другого и не было :-)


Вот именно, лучше решите, где лучше семафоры, а где мьютексы. А в таком стиле невозможно определить о чем спор. ;)