Is safe and good design AllocateHWND to respond more than one thread?

1
votes

It's known that, in cases when one needs comunicate between UI thread and working thread, an hidden window must be created because of thread safety(handle reconstruction).

For exemplify:

  • Form1 has N dynamicaly created TProgressBar instances with the same name of a background running .
  • Is always garanteed that WM_REFRESH will only be called inside Task Thread.

  • Form1 has H : THandle property that allocates the following procedure:

    procedure RefreshStat(var Message: TMessage); message WM_REFRESH;

  • Inside RefreshStat, in cases when there is only 1 background thread I could easily use L and W parameter to map Task Id and position.

I don't know if the title says what I want to know, but let's imagine if we have an application that has multiple background tasks running.
In my case I use TProgressBar to report progress the done.

Does AllocateHwnd garantee that all messages arrives with no race condition the hidden window?
What happens if two or more tasks post the message at the same time?

If this needs to be controled manually, I wonder if there is something else to do besides creating another message loop system in the custom message.

I hope the question is clear enough.

1
multithreadingdelphiwinapidelphi-6
Don't use THandle for a window. Use HWND. You use THandle for something that can be passed to CloseHandle, that is the Windows type HANDLE. – David Heffernan
@Matheus, how do you want to update those progress bars from that hidden window ? In other words, how do you want to synchronize that hidden window with your form ? Wouldn't that be overcomplicated ? It might be enough for you to post directly progress bar messages to the controls on your form. – TLama
@TLama The issue is window re-creation. The background tasks cannot use a VCL window handle since it can, and often does, get destroyed and re-creation. Hence the form needs a hidden window whose lifetime is deterministic. – David Heffernan
@David, at progress bar creation/destruction, the form won't get re-created. Why would it happen ? And I can't see the reason why would I destroy such monitoring form by myself. The same applies for progress bars. Why would I destroy progress bar of a running task ? Maybe I'm missing something, but I can't see anything dangerous in posting messages directly to PBs. – TLama
@TLama We are not talking about destroying VCL objects, rather it is windows that get re-created. Many property changes lead to window re-creation. – David Heffernan

1 Answers

5
votes

The message queue associated with a thread is a threadsafe queue. Both synchronous and asynchronous messages from multiple other thread are delivered safely no harmful date races. There is no need for any external synchronization when calling the Windows message API functions like SendMessage and PostMessage.

If two threads post or send messages to the same window at the same time, then there is no guarantee as to which message will be processed first. This is what is known as a benign race condition. If you want one message to be processed before the other then you must impose an ordering.