线程不接收消息

发布于 2024-07-14 12:05:21 字数 1847 浏览 2 评论 0原文

我的 Delphi 应用程序中有一个线程有一个消息等待循环。 每次它收到消息时,它就会开始做一些工作。 以下是该线程的执行过程:

procedure TMyThread.Execute;
begin
  while GetMessage(Msg, 0, 0, 0) and not Terminated do
  begin
    {thread message}
    if Msg.hwnd = 0 then
    begin
      ...
    end
    else
      DispatchMessage(Msg);
  end;
end;

使用我的应用程序进行一些测试,我发现 GetMessage 函数依赖于主线程。 我的意思是,当主线程正在做一些工作时,即使线程正在等待接收消息,我的线程中的 GetMessage 函数也不会返回(该消息是由另一个线程使用 PostThreadMessage 函数发送的:PostMessage( MyThreadId, WM_MyMessage, 0, 0))。

仅当主线程完成其工作或调用 Application.ProcessMessages 方法时,GetMessage 才会返回并且我的线程开始执行其工作。 实现这种线程间通信,我确信我的线程将独立工作,并且我绝不会期望直接发送到线程的消息的接收将依赖于主线程。

在进行测试时,我在主线程中使用了 WaitForSingleObject 函数,等待事件几秒钟。 这时我注意到我的线程没有做任何工作,即使消息是由另一个线程发送给它的。 当WaitForSingleObject函数最终完成等待并且主线程变得空闲时,我线程中的GetMessage函数返回。

有人可以解释一下为什么它会这样工作吗? 有解决方法吗? 我想让我的线程独立接收消息。 我的所有线程都是由主线程创建的。 可能是这个原因吗?

提前感谢您的帮助。

马吕斯。


Mghie,你又完全正确了(你可能还记得,你最近帮我处理了消息传递的事情)。 正如您所建议的, GetMessage 立即返回,但实际上,在调用主窗口方法时线程挂起:

procedure TMyThread.Execute;
begin
  while GetMessage(Msg, 0, 0, 0) and not Terminated do
  begin
    {thread message}
    if Msg.hwnd = 0 then
    begin
      ...
      if Assigned(FOnCommEventMethod) then
        FOnCommEventMethod(FCommEventsQueueItem);
      ...
    end
    else
      DispatchMessage(Msg);
  end;
end;

FOnCommEventMethod 是对象的方法,声明为“对象的过程(EventMask:Cardinal);” (该线程处理串行端口事件)。 在本例中,FOnCommEventMethod 被分配了一个属于主窗体类的过程。 当我的线程调用该方法时,线程将挂起,等待主线程完成其工作。

怎么会? 正如您所看到的,我没有使用 Synchronize() 方法来调用此过程。 因此我不希望我的线程与主线程同步。 它是隐式发生的吗? 顺便说一句,我知道任何 GUI 组件都不应该被除主线程之外的任何其他线程访问,因此应该使用 Synchronize 方法,但我现在只做一些快速测试。

回到 WaitForSingleObject 主题,我知道我不应该使用它,但这只是一个测试,(碰巧)我注意到了这个问题。

感谢您的帮助。 如果你不帮助我,我可能会摆脱消息传递并使用事件来代替,最后我会注意到这不是原因:-)。

There is a thread in my Delphi application that has a message-waiting loop. Every time it receives a message, it starts doing some work. Here is the execute procedure of that thread:

procedure TMyThread.Execute;
begin
  while GetMessage(Msg, 0, 0, 0) and not Terminated do
  begin
    {thread message}
    if Msg.hwnd = 0 then
    begin
      ...
    end
    else
      DispatchMessage(Msg);
  end;
end;

Doing some tests using my application I discovered that the GetMessage function is main thread dependent. By this I mean that while the main thread is doing some work, the GetMessage function in my thread does not return even though a message is waiting to be received by it (the message is sent by yet another thread using the PostThreadMessage funciton: PostMessage(MyThreadId, WM_MyMessage, 0, 0)).

Only when the main thread finishes its work or the Application.ProcessMessages method is called, does GetMessage return and my thread starts doing its work. Implementing this kind of inter-thread communication I was sure that my threads would work independently and I would never expect that the reception of messages sent directly to a thread would be dependent on the main thread.

Doing the tests I used the WaitForSingleObject function in the main thread, waiting for an event for a few seconds. This is when I noticed that my thread was not doing any work even though messages were sent to it by another thread. When the WaitForSingleObject function finally finished waiting and the main thread became idle, the GetMessage function in my thread returned.

Could somebody explain me why it works this way? Is there a workaround to that? I would like to make my thread receive messages independently. All my threads are created by the main thread. May this be the reason?

Thanks for your help in advance.

Mariusz.


Mghie, you were absolutely right again (you have helped me with the messaging stuff lately, you might remember). As you suggested, GetMessage returns immediately, but the thread hangs, in fact, on a call to a main window method:

procedure TMyThread.Execute;
begin
  while GetMessage(Msg, 0, 0, 0) and not Terminated do
  begin
    {thread message}
    if Msg.hwnd = 0 then
    begin
      ...
      if Assigned(FOnCommEventMethod) then
        FOnCommEventMethod(FCommEventsQueueItem);
      ...
    end
    else
      DispatchMessage(Msg);
  end;
end;

FOnCommEventMethod is a method of object, declared as 'procedure (EventMask: Cardinal) of object;' (this thread handles serial port events). In this case the FOnCommEventMethod was assigned a procedure belonging to the main form class. When the method is called by my thread, the thread hangs waiting for the main thread to finish its work.

How come? As you can see, I don't use the Synchronize() method to call this procedure. Therefore I would not expect my thread to be synchronizing with the main thread. Does it happen implicitly? BTW, I understand that any GUI components should not be accessed by any other threads but the main one, so the Synchronize method should be used, but I am only doing some quick tests now.

Comming back to the WaitForSingleObject subject, I know I should not use it, but it was only a test thanks to which (coincidentally) I noticed the problem.

Thanks for your help. If you did not help me, I would probably get rid of messaging and use events instead, and finally I would notice that it was not the reason :-).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

瀟灑尐姊 2024-07-21 12:05:21

只有当主线程完成其工作或调用 Application.ProcessMessages 方法时,GetMessage 才会返回并且我的线程开始执行其工作。

我怀疑这是否真的发生了。 据我所知,只要您不使用其他同步线程的方法,例如 SendMessage(),两个消息循环应该彼此独立。 您确定线程确实在 GetMessage() 内部阻塞,而不是在 Synchronize() 内部阻塞(内部使用 SendMessage() )?

在进行测试时,我在主线程中使用了 WaitForSingleObject 函数,等待事件几秒钟。

您绝对不应该在主线程中使用超时时间超过 100 毫秒的 WaitForSingleObject(),因为这会让您的 GUI 显得缓慢。 事实上,我建议您根本不要在主线程中使用它,因为这只是轮询。 请改为从您的工作线程发布消息。

Only when the main thread finishes its work or the Application.ProcessMessages method is called, does GetMessage return and my thread starts doing its work.

I doubt that this is really what's happening. AFAIK the two message loops should be independent of each other, as long as you don't use other means of synchronizing the threads, like SendMessage(). Are you sure that the thread does indeed block inside of GetMessage() and not inside of Synchronize() (which is using SendMessage() internally)?

Doing the tests I used the WaitForSingleObject function in the main thread, waiting for an event for a few seconds.

You should never use WaitForSingleObject() in the main thread with a timeout longer than say 100 milliseconds, as this will make your GUI appear sluggish. In fact I would advise you to not use it at all in the main thread, because this is simply polling. Post a message from your worker thread instead.

欢你一世 2024-07-21 12:05:21

您可以为您的线程创建消息队列。 只需在您的线程中执行以下代码:

MSG msg;
PeekMessage(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE);
SetEvent(messageQueueReady);
while (GetMessage(&msg, NULL, 0, 0)) 
{
    ...// do message processing here
}

对 PeekMessage 的调用强制操作系统为您的线程创建一个新的消息队列。 您必须确保对此进行同步,即您必须等待(例如通过WaitForSingleObject)调用成功,然后才能将消息发布到该线程(例如通过PostThreadMessage)。 这就是上例中调用 SetEvent API 的原因。

编辑:抱歉,示例是用 C 语言编写的,希望您没问题。

You can create a message queue for your thread. Just execute the following code in your thread:

MSG msg;
PeekMessage(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE);
SetEvent(messageQueueReady);
while (GetMessage(&msg, NULL, 0, 0)) 
{
    ...// do message processing here
}

The call to PeekMessage forces the OS to create a new message queue for your thread. You have to make sure to synchronize this, i.e. you have to wait (e.g. via WaitForSingleObject) for the call to succeed before you post messages to this thread (e.g. via PostThreadMessage). This is why there's a call to the SetEvent API in the example above.

Edit: Sorry for the example being in C, hope that's ok for you.

谎言 2024-07-21 12:05:21

请参阅 http://groups.google .com/group/borland.public.delphi.language.delphi.win32/browse_thread/thread/cf368834a606321b

请求蒸馏,留下许多隐藏着魔鬼的粗糙细节:主(或VCL)线程是特殊的在 Delphi 中,因为引擎盖下的很多东西都不是线程安全的,并且它拥有所有这些东西。 像消息循环这样的事情最终会因为与底层 VCL 线程同步的事情而等待。 许多人对此都有理论。 似乎最有效的方法是使 VCL 线程尽可能轻量/响应迅速,以最大程度地减少等待。 每个人都非常同意这一点。 有些人对其他可能有效的事情有想法,但其他人认为他们只是自找麻烦。

See http://groups.google.com/group/borland.public.delphi.language.delphi.win32/browse_thread/thread/cf368834a606321b

Requested distillation, leaving off lots of gnarly details in which the devil hides: the main (or VCL) thread is special in Delphi because lots of things under the hood aren't thread safe, and it owns them all. Things like the message loop wind up waiting because of things that synchronize with the VCL thread under the hood. Many people have theories about this. The thing that seems to work the best is keep your VCL thread as light / responsive as possible to minimize waits. Everyone pretty much agrees on this. Some people have ideas about other things that might work but other people think they are just asking for trouble.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文