This measures how many webpages can be served up in an hour, or how long it takes to render a DVD. Usually this type of performance tuning is only needed on server type applications, or other heavy-duty processing. This is the number of jobs you can process in a specific amount of time. The other performance characteristic is throughput. They don't care if it takes 15 seconds to do something hard, as long as when they click on a button or a menu, it reacts instantly. This gives the app a quick "snapiness" that is what most users want when they talk about performance. It does things like painting a window, but not rendering the data to be displayed. Once the worker is done, it notifies the GUI thread, which then updates the display to reflect any changes.
IGETTER MORE THREADS WINDOWS
The GUI thread needs to basically convert windows messages into work-items and let your worker queue handle the heavy work. This is one of the reasons it's best to have a single thread devoted to handling the GUI (other reasons have been mentioned in other answers). You don't care how many clicks per second you can process, but you do care about showing some response within a 10th of a second or so (ideally less). If you're writing a GUI app, the UI needs to be responsive. Note that there are two different performance goals, and you haven't stated which you are targetting: throughput and responsiveness. Finally, the windows message queue is not design to handle cases like queue saturation, thread starvation, or message re-queuing these are cases that often arise in implementing a decent message queing solution. This may not be enough to base a clean messaging model on. Each windows message has a code, and a 32-bit parameter. Furthermore, windows messages carry very little data - it is not an object-based model. Unless this is the problem you are trying to solve, I would advise against using it as a general message dispatching solution. This mechanism comes with significant overhead and is really only intended for pumping messages through an windows application's UI loop. NET, C++/STL, Java, etc.Īs to your second question, whether to use standard windows message dispatch mechanism. There are many good thread pooling libraries available for most platforms, including. The number of threads can even scale at runtime to adapt to the realtime message load being experienced. The benefits of this design is that you can scale the number of threads in the thread in proportion to the processing environment or the message load. #3 Multiple threads for all messages => thread pool with multiple threads #2 Thread per N message types => thread pool with N threads, each thread peeks at the queue to find appropriate message types #1 Single thread processes all messages => thread pool with only one thread A thread pool implementation can model all three thread-distribution examples you have. All messages arrive on a single queue, multiple threads wait on the queue and process messages as they arrive. In my experience, the most effective threading architecture would be to employ a thread pool. resilience to thread failure / long operations is desirable.scalability is the key design requirement (e.g.you want the app to scale well across processing architectures (i.e.it is desirable to respond to an arriving message as quickly as possible.messages are independent and don't rely too heavily on shared resources.However, if we adopt the following assumptions: There isn't necessarily a single "correct" approach to designing the threading model for such an application. The specific choice of threading model should be driven by the nature of the problem you are trying to solve. But ignoring that, seems that multiple threads only add overhead (Thread switches, not to mention more complicated sync situations).Īnd another question: Would you recommend to implement such a system upon the standard Windows messaging system, or to implement a separate queue mechanism, and why?
Plus, if any thread is waiting for an external event, other threads can still process unrelated messages. Obviously, the last two options benefit from a situation where there's more than one processor. So, would there be any significant performance differences between the three? Having multiple threads that share and process a single message queue.Having separate threads for separate message types (General, UI, Networking, etc.).Having a single thread process all of the messages.much like a standard windows app only that it extensively uses messaging for internal operations, what would be the best approach regarding to threading?Īs I see it, there are basically three approaches (if you have any other setup in mind, please share):
0 kommentar(er)
