Alternative for Postmessage and sendmessage

i have a program which is using several threads to execute some task. Each thread is having a bunch of task to execute. after executing one of them, each thred will call a post message to main screen to update logs.

Now i have sixty thousand tasks ten thousand for each thread - six threads- after executing each task thread is calling post messages. but because of these post messages my application becomes very busy and looks like it hanged.

if i remove post messages...every thing works fine. But i cannot call the procedure directly because it uses ui controls and ui control开发者_如何学编程s are not thread safe and calling procedure directly from thread will lead to other errors.

so is there any alternative available for postmessage and send message.

Thanks, bASIL

The problem is that there are two message queues for posted messages. The result of this is that your posted messages are always processed before any Paint, Input, or Timer messages.

This means that you are flooding the message queue with a few hundred thousand messages. These messages will always get processed before paint and user messages - making your application appear to hang.

The common way to solve this is to use a timer; have your code start a very short duration (e.g. 0 ms) timer.

Clarification

Timer messages (WM_TIMER), like Paint messages (WM_PAINT) and Input messages (e.g. WM_MOUSEMOVE, WM_KEYDOWN) are processed after posted messages. Timer messages specifically are processed after input and paint messages.

This means that your application will respond to user events and paint requests before it handles the next WM_TIMER message. You can harness this behavior by using a Timer (and it's WM_TIMER message), rather than posting a message yourself (which would always take priority over paint and input messages).

When timers fire they send a WM_TIMER message. This message will always be handled after any input and paint messages; making your application appear responsive.

The other upside of setting a timer is that it forces you to "queue up" all the items you have processed in a (thread safe) list. You combine a few thousand work items into one "timer", saving the system from having to generate and process thousands of needless messages.

Bonus Chatter

...messages are processed in the following order:

• Sent messages
• Posted messages
• Input (hardware) messages and system internal events
• Sent messages (again)
• WM_PAINT messages
• WM_TIMER messages

Update: You should not have a timer polling, that's just wasteful and wrong. Your threads should "set a flag" (i.e. the timer). This allows your main thread to actually go idle, only waking when there is something to do.

Update Two:

Pseudo-code that demonstrates that order of message generation is not preserved:

//Code is public domain. No attribution required.
const
  WM_ProcessNextItem = WM_APP+3;

procedure WindowProc(var Message: TMessage)
begin
   case Message.Msg of
   WM_Paint: PaintControl(g_dc);
   WM_ProcessNextItem:
      begin
          ProcessNextItem();
          Self.Invalidate; //Invalidate ourselves to trigger a wm_paint

          //Post a message to ourselves so that we process the next 
          //item after any paints and mouse/keyboard/close/quit messages
          //have been handled
          PostMessage(g_dc, WM_ProcessNextItem, 0, 0); 
      end;
   else
      DefWindowProc(g_dc, Message.Msg, Message.wParam, Message.lParam);
   end;
end;

Even though i generate a WM_ProcessNextItem after i generate a WM_PAINT message (i.e. Invalidate), the WM_PAINT will never get processed, because there is always another posted message before it. And as MSDN says, paint messages will only appear if there are no other posted messages.

Update Three: Yes there is only message queue, but here's why we don't care:

Sent and posted messages

The terminology I will use here is nonstandard, but I'm using it because I think it's a little clearer than the standard terminology. For the purpose of this discussion, I'm going to say that the messages associated with a thread fall into three buckets rather than the more standard two:

What I'll call them            Standard terminology
===========================    =============================
Incoming sent messages         Non-queued messages
Posted messages            \_  
Input messages             /   Queued messages

In reality, the message breakdown is more complicated than this, but we'll stick to the above model for now, because it's "true enough."

The Old New Thing, Practical Development Throughout the Evolution of Windows
by Raymond Chen
ISBN 0-321-44030-7
Copyright © 2007 Pearson Education, Inc.
Chapter 15 - How Window Messages Are Delivered and Retrieved, Page 358

It's easier to imagine there are two message queues. No messages in the "second" one will be read until the "first" queue is empty; and the OP is never letting the first queue drain. As a result none of the "paint" and "input" messages in the second queue are getting processed, making the application appear to hang.

This is a simplification of what actually goes on, but it's close enough for the purposes of this discussion.

Update Four

The problem isn't necessarily that you are "flooding" the input queue with your messages. Your application can be unresponsive with only one message. As long as you have one posted message in the queue, it will be processed before any other message.

Imagine a series of events happen:

• Mouse is moved (WM_MOUSEMOVE)
• Mouse left button is pushed down (WM_LBUTTONDOWN)
• Mouse left button is released (WM_LBUTTONUP)
• The user moves another window out of the way, causing your app to need to repaint (WM_PAINT)
• Your thread has an item ready, and Posts a notification (WM_ProcessNextItem)

Your application's main message loop (which calls GetMessage) will not receive messages in the order in which they happened. It will retrieve the WM_ProcessNextItem message. This removes the message from the queue, leaving:

• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP
• WM_PAINT

While you process your item the user moves the mouse some more, and clicks randomly:

• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP
• WM_PAINT
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP

In response to your WM_ProcessNextItem you post another message back to yourself. You do this because you want to process the outstanding messages first, before continuing to process more items. This will add another posted message to the queue:

• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP
• WM_PAINT
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP
• WM_ProcessNextItem

The problem starts to become apparent. The next call to GetMessage will retrieve WM_ProcessNextItem, leaving the application with a backlog of paint and input messages:

• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP
• WM_PAINT
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP
• WM_MOUSEMOVE
• WM_MOUSEMOVE
• WM_LBUTTONDOWN
• WM_LBUTTONUP

The solution is to take advantage of the out-of-order processing of messages. Posted messages are always processed before Paint/Input/Timer messages: don't use a posted message. You can think of the message queue as being divided into two groups: Posted messages and Input messages. Rather than causing the situation where the "Posted" messages queue is never allowed to empty:

Posted messages      Input messages
==================   =====================
WM_ProcessNextItem   WM_MOUSEMOVE
                     WM_LBUTTONDOWN
                     WM_LBUTTONUP
                     WM_PAINT

You an use a WM_TIMER message:

Posted messages      Input messages
==================   =====================
                     WM_MOUSEMOVE
                     WM_LBUTTONDOWN
                     WM_LBUTTONUP
                     WM_PAINT
                     WM_TIMER

Nitpickers Corner: This description of two queues isn't strictly true, but it's true enough. How Windows delivers messages in the documented order is an internal implementation detail, subject to change at any time.

It's important to note that you're not polling with a timer, that would be bad™. Instead you're firing a one-shot timer as a mechanism to generate a WM_TIMER message. You're doing this because you know that timer messages will not take priority over paint or input messages.

Using a timer has another usability advantage. Between WM_PAINT, WM_TIMER, and input messages, there is out-of-order processing to them as well:

• input messages, then
• WM_PAINT, then
• WM_TIMER

If you use a timer to notify your main thread, you can also be guaranteed that you will process paint and user input sooner. This ensures that your application remains responsive. It's a usability enhancement and you get it for free.

You are going to struggle to find anything better than PostMessage. My guess is that your problem is that you are updating UI too frequently and your queue is becoming saturated because you cannot service it quickly enough. How about skipping updates if you updated less than a second ago say? If that restores responsiveness then you can consider a more robust solution.

Instead of posting messages, you can put messages in a thread safe queue.

In your main thread, use a timer event to drain the queue.

To remain responsive though, do not stay in the timer event too long.

In many cases I have found this better than posting messages.

In Delphi XE there is a class called TThreadedQueue which you can use.

Edit :

I uploaded a sample sort application utilizing different thread to GUI techniques.

See ThreadedQueueDemo

I have done this many times. Have the posted message from the threads update a "cache" on the main form. Have a timer on the main form (set to around 100 ms, or less if you need to) update the main form from the cache. This way the amount of work done per posted message is very small, so the application will spend less time processing and your application will appear "responsive".

You can create a new thread for updating logs and in the log threads call TLogThread.Synchronize to update the UI controls that are in the main app thread... or just call TWorkerThread.Synchronize to update the logs from your worker threads.