вариант thread pool

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

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

сделай per cpu очереди без блокировок --- это в какую сторону смотреть?

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

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))

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

Был тут один вариант... Не взлетит... Поздно, уже скомпилялось (если сможешь сконпелять :))

UNIQS << 1

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

pipe

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

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

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