треды

1-й вариант условно годится (впрочем, см. дальше) лишь в одном случае -- если у тебя мастер-тред ЗАВЕДОМО монополизирует один процессор. Так, кстати, обычно поступает MPICH...

Он меня ДОСТАЛ! Только для пузомерок, специально для этого написанных, годится. В любой реальной задаче ТАК ДЕЛАТЬ НЕЛЬЗЯ! (согласно моему опыту, конечно).

2-й вариант -- нормально, только всегда надо думать про оптимизацию блокировок. На этот счет есть несколько (квази-)математических теорий, кстати!

Хм...а с пайпами не проще будет? INPUT открывает пайп на запись, куда пишет данные. Треды в очереди читают из этого пайпа, если данных нет - то они тупо висят на вызове read(). Если данные большого размера - то в пайп мона писать указатель на данные. Тред OUTPUT открывает пайп на чтение, в который пишут треды. Так же висит на вызове read() когда данных нету.

AFAIK, read() и write() на пайпе атомарны для данных, размер который не превышает 512 байт (точное значение в каком-то заголовочном файле)

> ...а с пайпами не проще будет?

Это ЧАСТНОСТИ, про которые речи вообще не было. Речь шло про общую страрегию синхронизации.

По-моему операции read() и write() на пайпе могут решить проблему синхронизации. По крайней мере, не надо искать кто свободен кто занят, не нужны блокировки

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

Возможно, я недопонял задачу, но ИМХО проще было бы через сокеты: INPUT хранит отдельно списки занятых и свободных тредов, при появлении данных извлекает из списка свободных тредов один и пихает туда чё-нибудь. Тред висит соответственно на poll/select когда не занят. OUTPUT юзает poll/select по всем тредам. Когда получит данное из треда, по сокету же передаёт в INPUT информацию чё такой-то тред уже освободился, из-за чего INPUT перенесёт ево из списка занятых в список свободных.

Я [другой anonymous] сделал бы следующий вывод: второй вариант - однозначно. Выбор механизма для организации очередей, который требовал бы поменьше блокировок, можно оставить на потом, а для начала стоит лишь сделать какую-нибудь правильную обертку вокруг мютексов и STLных очередей, которые кажутся удачной starting point.

Под Windows я бы смотрел в сторону Slists (они реализованы на Interlocked операциях), но их аналога, доступного под Linux, я, к сожалению, не знаю.

Использование средств уровня OS (сокеты, пайпы и т.д.) кажется неоправданным из-за несравнимо бОльших накладных расходов, если мы, конечно, не имеем ввиду чего-то более продвинутого, чем SMP архитектура.

Еще я бы крепко подумал, нужны ли мне нити вообще, или лучше все это делать на уровне процессов. Вот тогда пайпы с сокетами довольно уместны.

>но их аналога, доступного под Linux, я, к сожалению, не знаю.

Эти 10 строчек написать чтоли проблема.. поиск на comp.programming.threads

Как-то натыкался и на Си++ либу с кучей всевозможных lock-free/wait-free алгоритмов кроссплатформеную..

>Как-то натыкался и на Си++ либу с кучей всевозможных >lock-free/wait-free алгоритмов кроссплатформеную..

lock-free/wait-free ??? Интересно... Название не подскажите ?

pipe вроде не идеальный вариант.

Правильно ли я понимаю что подобную read на pipe блокировку можно сделать на pthread_cond_wait в тредах и pthread_cond_signal в INPUT ? имхо так красивей и функциональней...

anonymous (*) (11.09.2006 9:50:33):

> Выбор механизма для организации очередей, который требовал бы поменьше блокировок, можно оставить на потом, а для начала стоит лишь сделать какую-нибудь правильную обертку вокруг мютексов и STLных очередей, которые кажутся удачной starting point.

А я бы сделал ровно наоборот: в зависимости от возможностей оптимизации блокировок оптимальными будут совершенно различные механизмы.

> Под Windows я бы смотрел в сторону Slists (они реализованы на Interlocked операциях), но их аналога, доступного под Linux, я, к сожалению, не знаю.

Только самодеятельность с привлечением assembler + compiler intrinsics -- в Це, к сожалению, такого нет... Впрочем, вожможно, есть уже готовое?

Кстати, как я понимяю, в Вындузе оно работает только на IA-32?

> Еще я бы крепко подумал, нужны ли мне нити вообще, или лучше все это делать на уровне процессов. Вот тогда пайпы с сокетами довольно уместны.

+1

В 90% нитки вредны (особенено в виде пула), и все ЗНАЧИТЕЛЬНО проще делается на процессах (и работает быстрее!) с синхронизацией пайпами.