LINUX.ORG.RU
Форум — Development  

вариант thread pool

 , ,


1

1

добрый день,

Посоветуйте плз как организовать получше логику для решения задачки.

Есть главный поток (назовем main) который читает сообщения(джобы) из входной очереди сообщений. Каждое такое сообщение содержит ID. Прочитанное сообщение надо далее передать определенному потоку (worker), который ждет сообщения только с этим ID (в воркерах используется fsm).

К примеру, может быть 1024 уникальных ID. И я создаю заранее 1024 потока. Как передавать сообщения отдельным потокам?

В голове крутится вариант, что каждый поток worker должен иметь доступ к своей очереди сообщений, в которую пишет main поток, на основе полученного ID сообщения из входной очереди. Или есть варианты получше и более стандарнтые?

заранее спасибо,

mpi для этого вроде придумали. Но вопрос: нужны ли эти 1024 потока?! Очень легко получить не прирост производительности, а наоборот.

Silerus ★★★★
()

Ну если задач мало, но они долгие, сделай общую очередь и пусть треды слушают на pthread cond var и ее разгребают. Если задач много и тебе важен отклик, сделай per cpu очереди без блокировок.

kirk_johnson ★☆
()

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

u32 threads[UNIQS];
u32 pipes[UNIQS << 1];

// init
for (i = 0; i < UNIQS; i++) {
   threads[i] = thread_create<...>;
   pipe(&(pipes[i * 2 + 0])); // main -> thread
   pipe(&(pipes[i * 2 + 1])); // thread -> main
}

<..>

// loop
receive_msg(&msg);
write(pipes[msg.id * 2 + 0], &msg, sizeof(msg))

Это концепт, суть вы уловили.

PPP328 ★★★★★
()
Ответ на: комментарий от PPP328

UNIQS << 1

позёр дешёвый

pipe

Очередь один источник - один приёмник пишется мало того, что lock-free, но и wait-free (google в помощь).

Ну и вообще создавать 1024 потока разумно на 1024-ядерной машине.

Begemoth ★★★★★
()
Последнее исправление: Begemoth (всего исправлений: 1)
Ответ на: комментарий от elmir_k

Некоторые шибко умные манагеры проэктами раньше смотрели на 1024 ведра и цельнотянутый велосипед, разобранный еще на «RSDN-е» пытались приделать к проЭктам, вопреки возражениям разработчиков. Потом ВНЕЗАПНО выяснялось, что мускульный коннектор один фиг блокирующий и очередь без блокировок нам таки не упала от слова совсем, но раз внедряя переписали велосипед под стд атомики, которые в велосипеде накостыливались, то вырезать не стали :) Ну или прочитай от корки до корки «Concurrency in action. Practical multithreading» — пофиг что ничо не поймешь :)

slackwarrior ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development