Thread: Windows Messages Queuing Up Whilst Looping

You are correct - your windows message loop is unable to process windows messages whilst it is stuck within a message handler within itself.

There are several ways of doing this, some easier to understand, some more efficient.

The easiest to understand method is to implement your "loop" as a state machine. It does a small amount of work then saves it's position and releases the CPU. When the Windows loop gets back to the state machine, it reloads it's last saved state and does a bit more, then saves and releases again. This is effective for releatively simple tasks.

The better way to do it is to use a seperate worker thread to process the loop leaving the Windows processing loop in the main thread, that way, both loops can run "at the same time". To do it this way, you would need to start a thread with "combat loop" as a function. The thread will run until that function returns. The simplest way to start a thread is with the beginthread() API routine. Multithreading is a very big area, with a lot of concepts and gotcha's - to big to cover in a single message - my multithreading tutorial on my old site had 11 chapters, and still was only the basics really.

I agree with adrianxw. The "beginthread()" solution would work. It's because it's in a "do ... while" loop, which WILL cause an application to freeze if it's not in a thread, and if it lasts long enough. So, I will suggest "beginthread()". Just thought I would add my thoughts.

Let me point out that if the combat loop has been started and you enter combat again you could have serveral combat loops running, so you need some sort of thread sycronisation. The easiest way to do it for what your doing is this:
The first thing the combat loop dose is set a global variable to true (something like bInCombat) before your main loop calls beginthread it checks the variable and only enters the combat loop if its not allready running.
That is just one Option and it depends on your program.

>>so you need some sort of thread sycronisation.

Critical sections.


Another way is

Start the combat loop,

Run the loop until it writes one line of text to the edit or finishes a round.

Then send your app a message (SendMessage()) User defined message is good for this. This will get processed in order (ie other msg's will get processed)

Stop the combat loop.

When the app catches up and process the message you sent, start the combat loop again.

Repeat until the combat loop is finished.

>>>
The first thing the combat loop dose is set a global variable to true (something like bInCombat) before your main loop calls beginthread it checks the variable and only enters the combat loop if its not allready running.
<<<

That will not always work. A thread, any thread, can be pre-empted at any point in it's execution, that means part way through the execution of a line of code - remember, the code you see has been compiled.

Possible scenario:

Thread reads global variable, sees it is available, so tries to set it to say it is running, however, it gets pre-empted before it writes the value back.

Second thread reads the variable, sees it is available sets it, and starts running.

First thread runs again, completes writing the variable and also starts running.

... You now have two threads running both thinking they are the only ones there - disaster in the making.

You need to use OS level objects for thread synchronisation. Critical sections are the easiest to understand.

The easiest way to pass multiple parameters is to create a structure containing the values and pass a pointer to that structure to your thread function.

You should always free up dynamically allocated memory. If you do that, you do not need to do anything special because it is in a seperate thread.

If you use beginthread() you do not need to do anything other than execute a return from the thread function - it does everything for you, (that's why I suggested it).

If you use other thread routines to begin a thread, beginthreadex() for example, that is not the case. Things like the thread handle remain open and must be manually closed if you use this function for example.

adrian already explained why that wouldnt work faultlessly.
Imagine what happens after the test but before the assignment if your thread gets preempted. You may be able to get away with a double checked locking pattern to cut out some of the overhead but some sort of synchronization will be necessary.

As SC said - the problem occurs if the thread spinner gets pre-empted...

Code:

if (!bInThread) {
        // ... here...            
	bInThread = TRUE;
	beginthread(...);     // Should check return value.
}

... the test has been made and seen to be FALSE, however, it has not set it TRUE yet. Anything could happen, including another thread making the same test and suceeding in setting the flag TRUE, before this thread gets a chance to run again. When this one does, it sets the flag TRUE, (it may now already be so, but that doesn't matter), and spins a thread, when in fact, it should not have done.

... the test has been made and seen to be FALSE, however, it has not set it TRUE yet. Anything could happen, including another thread making the same test and suceeding in setting the flag TRUE, before this thread gets a chance to run again.

There is no other thread in the context of Mr Pickle's question or my reply. This code is placed in the window procedure. The window procedure, as you know, only runs in the one thread.

Therefore, it is entirely impossible to reach // ...here..., in more than one thread in the same process.

The scenario you are describing is multiple threads spinning threads. This is far more complex than Mr Pickle's application. Even in more complex applications I think it would be generally preferred to have one controller thread spinning multiple threads rather than multiple threads spinning their own threads.

Multiple threads spinning threads... I can't even make sense describing it. ;-',

I still think my code is perfectly safe in the context of Mr Pickle's application but I look forward to continuing the discussion.

Here is the revised code:

Code:

#include <windows.h>
#include <process.h>
#include "resource.h"
#define Display(s) SendDlgItemMessage(DialogWindow,\
  IDC_OUTPUT,EM_REPLACESEL,0,(LPARAM)((LPSTR)s))

static BOOL bInThread;

VOID CombatLoop(HWND DialogWindow)
{
  int counter;
  char Temp[100];
  for(counter=0;counter<=10;counter++) {
	wsprintf(Temp, "In Loop Number %d\r\n", counter);
	Display(Temp);
	Sleep(1000);
  }
  wsprintf(Temp, "Thread Has Finished\r\n");
  Display(Temp);

  bInThread = FALSE;
}

LRESULT CALLBACK ClientDlgProc(HWND DialogWindow, 
  UINT Message, 
  WPARAM wParam, 
  LPARAM lParam)
{
  switch(Message) {
    case WM_INITDIALOG:
      Display("Started Up..\r\n\r\n");
      return FALSE;
    break;

    case WM_COMMAND:
       switch (wParam) {
         case ID_QUIT:
           EndDialog(DialogWindow, FALSE);
         break;

         case ID_START:

         if (!bInThread) {
                  bInThread = TRUE;
                  _beginthread (CombatLoop, 0, DialogWindow);
         }
         break;

         case ID_NORTH:
            Display("North Button Pressed\r\n");
         break;

         default:
         break;
      }
    break;

    default:
    break;
  }
  return FALSE;
}

int APIENTRY WinMain(HINSTANCE hInstance, 
                                   HINSTANCE hPrevInstance, 
                                   LPSTR lpCmdLine, 
                                   int nCmdShow)
{
    DialogBox((HINSTANCE) hInstance, 
    MAKEINTRESOURCE(IDD_DIALOG), 
    NULL, (DLGPROC) ClientDlgProc);
    return 0;
}