Share via

[Beginner] Multithreading C++ Socket

sValentin 61 Reputation points
2025-01-14T17:52:25.7733333+00:00

In C++ (well I think in every programming language) what is better to do when dealing with multithreading socket?

  1. Cap the number of threads it can execute the requests so that you always have 1/2 thread available for accepting new connections? In this case I can see a situation where the threads might be I/O bottlenecked so they just wait instead of actually doing something else.
  2. Don't cap it? In this case can't you get in a situation where all threads are busy and a new connection isn't accepted so the client doesn't connect to the socket server?

I know it is a beginner question but I didn't found a truly definitive answer (except I guess if you ask Gemini/ChatGPT, but I would like an answer from someone that uses them, and not scraping the internet and maybe even getting wrong answers but answering like it is 100% sure it is right). For example you have a processor with 32 logical cores (16 physical with SMT / Hyper-Threading). Is it better to cap it to 31/30 threads for execution and keep 1/2 for only accepting connections, or leave it uncapped?

C++
C++
A high-level, general-purpose programming language, created as an extension of the C programming language, that has object-oriented, generic, and functional features in addition to facilities for low-level memory manipulation.
3,822 questions
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Bruce (SqlWork.com) 69,276 Reputation points
    2025-01-15T00:03:19.0133333+00:00

    it depends on app design. no threads are required to support multiple connections. for example node.js only uses a single thread for all sockets, but because it uses asynchronous I/O it still very fast.

    only one thread receives the connection. it can process the connection directly, create a new thread to process. or in a application like IIS, there is a receive thread pool, a send thread pool and process thread pool.

    as receiving and sending and are I/O bound, the the thread is often in a wait state (not using cpu). therefore its practical to have many more I/O threads than cores (hundred to thousands). the processing of the request uses cpu, but typical is often I/O bound using disk, databases or network calls, so again more threads than core makes a lot of sense.

    0 comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.