0

Good day all.

I am in the process of moving our server application (mostly UDP) from a thread-per-socket strategy to IOCP. The IOCP part works well, however the treads that send/receive the data don't do the actual data processing. For now they save the received packets in a std::deque protected by a critical section.

The real work is done by another thread which is bound by a 100 millisecond cycle. And there seems to be the problem, the insertion/retrieval from the deque introduces delays that cause logical problems down the road. Essentially I have a single consumer / multiple producers type of scenario.

I debugged and profiled and my conclusion is that it is a thread starvation. I tried to use an Event object to signal the thread that it can retrieve the data, but that also did not seem to help. Are there more efficient ways than using a CRITICAL_SECTION to protect the data structure?

Thanks in advance, Michael

MUXCAH
  • 205
  • 1
  • 6
  • 1
    When I faced a priority inversion issue in some embedded code, I switched to lock-free queues using this algorithm: https://groups.google.com/forum/#!topic/lock-free/Vd9xuHrLggE I'm sure there are other implementations which would work as well. – Dark Falcon Jun 22 '17 at 20:40
  • 2
    Is there a _very_ _very_ good reason why you're not using the IOCP queue as a single threaded producer ? – Michaël Roy Jun 22 '17 at 21:26
  • Michaël Roy: I start several threads that are waiting on the IO completion handle using GetQueuedCompletionStatus. I googled around and everyone recommends to start as many threads as there are cores (some suggest x2). Not sure that a single thread will be able to handle hundreds of sockets. – MUXCAH Jun 22 '17 at 21:34
  • 'The real work is done by another thread which is bound by a 100 millisecond cycle' - why? Why can you not signal the arrival of a buffer pointer onto the queue with a semaphore, or use a blocking queue class? – ThingyWotsit Jun 23 '17 at 04:54
  • @MUXCAH I think, (?), that what Michael is saying is that there is not much point in raising a thread pool to handle the results signaled by GetQueuedCompletionStatus() if you are just going to queue off the data to another thread/pool. – ThingyWotsit Jun 23 '17 at 04:57
  • Thanks to all this issue is now solved. – MUXCAH Jun 24 '17 at 03:28

0 Answers0