Home/ Questions/Q 8610371
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T04:06:51+00:00

I have an windows application that need’s to very fast process all incoming messages,

  • 0

I have an windows application that need’s to very fast process all incoming messages, or it will cripple system performance pretty hard i suppose. What i’ve thinked about is an some way to spawn and join threads for each message so that they will be processed sequentially. But that approach have serious problem: when i spawn thread and trying to join top thread how can i know if it’s available for join? Offcourse i can check if it’s joinable (i use std::thread) but while i will be doing that it could just become non-joinable and thread isn’t a mutex – i can’t just block it and check again. So what i need is some kind of deffered task pool or task query that would be non-blocking, atleast for message thread. Again i can just spawn thread that will wait for that query and add the task so it can be processed, but is it really good solution?

That wouldn’t be necessarily something working from the box, i can implement any concurent pattern.

inb4:
Windows, WinAPI, C++11, std::thread for threading.
Sorry for my english, can’t find time to improve it, really.

Thank you for your answer, it seem’s i did a mistake in problem descreption. Exactly i need only to let WNDPROC return it’s result ASAP, so next message can be poped from message queue. I need this because i log time when message was sent, so i need it done fast so it won’t affect that time measurement. Also those messages are afaik urgent for system and my window need to process them fast or it will somehow affect performance.

Again: i need to somehow move exact message processing to other thread, right now it look like this:


case WM_INPUT:
    int timestamp = PushTimeStampToAsyncTimestampQueue();
    launchLongChainOfMessageProcessing(message,timestamp);
    return 0;

I need to get rid of that launchLongChainOfMessageProcessing and replace it with something like 


case WM_INPUT:
    int timestamp = PushTimeStampToAsyncTimestampQueue();
    std::thread processThread([]() { do_work(message, timestamp);});
    return 0;
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You will find no method under the current Windows OS that is faster and more scalable for processing high-volume inbound messages than overlapped I/O using I/O Completion Ports (IOCP for short). It is incredibly scalable and extremely versatile.

    IOCP allows you to define a pool of threads and have those threads managed and scheduled by the IOCP subsystem, waiting for IO completion notifications on any IO-based system (sockets, pipes, files, anything, and even no IO-based system if you prefer; it makes for a fantastic work queue distribution system as well).

    I caution you to NOT spawn threads for processing highly eccentric concurrent connections. You want a thread pool that is stable, with a pool large enough so that when one blocks due to a stall on some call to kernel such as waiting on an event, a mutex, etc, another is dispatched work immediately. Spawning threads, setting up and tearing down context, is expensive, so avoid it, and thankfully IOCP is a beautiful solution for doing just that. its ability to bring another thread out of slumber when work is present and others are busy with other work is just outstanding.

    Were I setting up the system you’re describing (and given, you can only do so much justice to your end-goal with a few paragraphs on SO), I would use and IOCP-based solution without hesitation.

    EDIT After the OP updated the question I’m strangely going to stand by this answer, but in a rather twisted way. His desire it to offload processing of that message queue as fast as possible. While I would not choose a windows message queue for my async-delivery system, I’m sure he has his reasons.

    However, I stand by using an IOCP, based system to do the actual processing. The throughput and scalability are simply too good not to use for distributed work systems, and it seems that is what he has here. No code, but the general algorithm would be.

    1. Create an IOCP-based work crew, all threads waiting on GetQueueCompletionStatus().
    2. With each WM_INPUT received, gather whatever parameters you need, build your “item” for processing, and post the item to the IOCP-based work crew using PostQueuedCompletionStatus() (this, btw, is a most-handy thing to bury inside your work-crews “post” function).
    3. As each thread is awoken, it will have handed to them a work “item” to process.
    4. When done with an item, the pool thread goes back to GetQueueCompletionStatus().

    There are a plethora of sample IOCP-based work queues on the web, and most will be reasonable for this need. All, unless written by fiends, will have superior performance to just about anything else you can use under Windows precisely because IOCP’s are so tightly integerated into the schedular.

    • 0