Unithreaded design or multithreaded design? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

So here is my scenario: I read from a socket and based on the contents on the packet i put the packet into an appropriate queue. So if i have 10 queues there will be 10 if- else -ifs or 10 cases of a switch statement to select the proper queue. So, there can be atmost 10 comparisons.

Another way could be to ask the broadcaster/server to broadcast on 10 different ports where feed from each port will have packets for a single specific queue, on my end i can listen to each socket through a saperate thread(Or i can use a thread pool if the traffic on certain ports is less/non-uniform). So that now i dont have to select which queue the packet belongs to but now the phenomenon of conext switch is introduced.

From here my intelligence and technical knowledge prevent me going further. Any enligtenment over which approach will perform better?

Answer 1

It is a personal choice. If the traffic is adequate or less than obviously the first approach is better. It is thread-safe, thanks to thread confinement. Easier to maintain. The only issue is that - if an extra port is added then you will have to modify the code for an extra if clause.

But under heavy traffic, this might be better. Lesser packets will be lost if the buffer is full. Might perform better depending upon the number of cores but again can be buggy if not executed well.

If I were you, I would have gone ahead with the first one. Keep it simple.

Answer 2

If you are using windows check out IO completion ports (IOCP), if linux try epoll. Those tend to be most effective models on both systems respectively (in general case). Windows IOCP model can be nicely bound to the thread pool by the means of OS.