c - one-producer and multiple consumer : should I use N semaphore if there are N consumers and N types of products -

i have program 1 producer thread , n consumer threads. there n types of producet, set n fifo queues(products should delivered consumer in sequence). like: fifo_queue_t* fifo_queque[n].

the consumer threads blocked/waiting if there no products on fifo queue. consumer thread i, do:

        for(;;)         {             sem_wait(&sem[i]);             product = fetch_one_product(queue);             process(product);          } 

and producer, call sem_post(&semp[i]) when put product thread i fifo queue i.

it seems me have use n semaphores in case, , if n big, resource consumption big. there missing in thinking?

update:

 system proxy, , original design this: 

i have tcp server listening on port, listen(listenfd, 20);

the producer libpcap instance, capture tcp packets port, products capture packets(including ip/tcp header);

for each connfd=accept(listenfd). create thread responsible connfd. these threads consumers.

i create lookup table, fields in each entry are:

1 source ip/port, source address of incoming tcp connection, 2 fifo queue pointer: fifo queue of captured spacket 3 pthread id :  thread responsible tcp connection 

when producer thread fetch packet, parse source ip/port packet, lookup table, locate fifo queue , put in fifo queue.

when consumer thread gets notified there packets in fifo queue, fetches packets queue. , especially, intial 3-way packets: tcp syn, syn/ack , ack, needs maintain states information, mss, sack, etc. , needs put these packets(including tcp/ip header) udp payload, , send udp packets other remote hosts.

this seems design isn't going scale well. if have 1,000 different products, you'll have 1,000 different fifo queues, 1,000 semaphores, , 1,000 threads running. going impossible manage.

you'd better off single queue , small number of threads. threads can handle type of item. difficulty delivering items customer in order, won't normally problem. solve it, need add sequence number of sort when item sent customer, check sequence number , wait if it's not 1 expect.

you don't wait, of course, rather put item output queue blocked, waiting correct item come in. works if can guarantee thread won't crash , drop item. because if happens, output customer going stop. need sort of policy prevent permanent block: perhaps timeout says, "well, waited long enough. customer going item though it's out of order."

added in response comment:

so have single input queue filled producer, small number of consumer threads, each of can process type of product, , either n output queues (which seems excessive), or single output queue overflow allow buffering out-of-order items. i'll assume have small number of threads (perhaps one?) servicing output queues , sending items customers.

items come out of order should stay in overflow brief time. there because 2 (or more) items of same type dequeued close together, , latter 1 got finished processing before earlier one(s). should rare event, overflow bucket shouldn't large @ all. make overflow simple list, , scan sequentially no noticeable performance penalty.