I'm thinking that can cause problems. Will it interfere with the console's WM_PAINT and other messages? Do I have to only update the console in a critical section (or something similar)? The console is a child of the main window. I really don't understand what needs to be protected and what doesn't.
When dealing multi-threaded apps, you generally need to protect any resources that are shared between threads. There are exceptions to this, such as shared read-only data, but for the most part, it holds true.
To understand why you need to protect your out method running on the UI thread, consider what happens if two threads call the out method. If thread 2 writes "ABCDEFGHI..." and thread 3 writes "123456789...", the out method (running in thread 1) could very well display something unexpected such as "ABC123D45EFG6HI789" due to context switching inside the thread scheduler works.
In terms of synchronization, you can add a critical section as a member of the console class and then lock/unlock it inside the out method. Depending on how often you are calling the out method inside the threads and how much data you are writing, you may delay the processing of windows messages of the main thread. If that is the case, you might want to explore other approaches.
What is m_console and what is out(...)? You will get much more useful replies if you post minimally complete example code rather than meaningless code snippets.
When you want to communicate to a window from a worker thread, you should only post messages to the window, otherwise you may end up with a dead-lock. This means that you either need to dynamically allocate memory for the string you want to pass (if the messages are infrequent), or use a synchronized queue to hold the messages. The latter works better for frequent messages, because you shouldn't rely on the order in which messages will be handled by the message loop. You'll still need to post a message to the window to tell it to read more data from the queue.
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
The other problem you're got is that thread_flag should be defined as volatile.
Not withstanding anything other posts have said, when you have a variable like this that can be changed outside of the thread you need to inform the compiler that it cannot optimse use of the variable. In your while loop, the compiler may well have put the value of thread_flag into a register and never updates the register again, So it will always appear to be 1 irrespective of any changes made to it outside of the thread! Using volatile tells the complier to always get the value from memory when it is referenced.
Marking a variable as volatile guarantees nothing. 'volatile' is a compiler hint only, and implementation is compiler dependant.
Make sure you know how it works for your compiler before you use it. If you want guarantees and/or portability, you need to use actual synchronisation.
for proper use in multithreading, just guaranteeing an actual read (or write) is not enough, you also need guarantees that the compiler won't optimize/reorder code around the volatile read and/or write. And even that does not necessarily guarantee the exact behaviour you expect on a multi core machine.
Last edited by OReubens; February 25th, 2013 at 11:03 AM.