Handling user interface in a multi-threaded application (or being forced to have a UI-only main thread)

Question

In my application, I have a 'logging' window, which shows all the logging, warnings, errors of the application. Last year my application was still single-threaded so this worked [quite] good.

Now I am introducing multithreading. I quickly noticed that it's not a good idea to update the logging window from different threads. Reading some articles on keeping the UI in the main thread, I made a communication buffer, in which the other threads are adding their logging messages, and from which the main thread takes the messages and shows them in the logging window (this is done in the message loop).

Now, in a part of my application, the memory usage increases dramatically, because the separate threads are generating lots of logging messages, and the main thread cannot empty the communication buffer quickly enough. After the while the memory decreases again (if the other threads have finished their work and the main thread gradually empties the communication buffer).

I solved this problem by having a maximum size on the communication buffer, but then I run into a problem in the following situation:

• the main thread has to perform a complex action
• the main thread takes some parts of the action and let's separate threads execute this
• while the seperate threads are executing their logic, the main thread processes the results from the other threads and continues with its work if the other threads are finished

Problem is that in this situation, if the other threads perform logging, there is no UI-message loop, and so the communication buffer is filled, but not emptied.

I see two solutions in solving this problem:

• require the main thread to do regular polling of the communication buffer
• only performing user interface logic in the main thread (no other logic)

I think the second solution seems the best, but this may not that easy to introduce in a big application (in my case it performs mathematical simulations).

Are there any other solutions or tips? Or is one of the two proposed the best, easiest, most-pragmatic solution?

Thanks, Patrick

Answer 1

Let's make some order first.

• you may not hold UI processing for any time U would have noticed, or he will be frustrated
• you may still perform long operations in the UI thread. this is done by means of PeakMessage loop. If you design one or more proper peakmessage loops, you do not need multithreading, unless for performance optimization.
• you may consider MsgWaitForSingleObject() loop instead of GetMessage if you want to communicate with threads efficiently (always better than polling)

Therefore, if you do not redesign your message loop

• There's no way you can perform syncronous requests from other threads
• You may design a separate thread for the logging
• All non-UI logic will have to be elsewhere.

About the memory problem:

• it is a bad design to have one thread able to allocate all memory if another thread is stuck. Such dependency is a clear recipe for a disaster.
• If the buffer is limited, you need to decide what happens when it's overrun. You have two options - suspend the thread or discard the message.

UI code:

It is possible to design logger code that would display messages with incredible speed. Such designs are complicated, rely on sophisticated caching and arranging data for fast access, viewport management and rendering only the part that corresponds to actual pixels that the user is looking at.

For most applications it is just a gimmick, because users do not read very fast. Most of the time it is better to design a different approach to showing logs, perhaps a stateful UI to let user choose what is interesting to him at the moment. Spy++ for example, some sysinternals tools like regmon, filemon are incredibly fast in showing their own logs. You can have a look at their source code.