AllocateHwnd is not Thread-Safe
[This article also serves as announcement of DSiWin32 1.26.] [Update: Reported as QC #47559. Vote for it!] You're probably asking yourself - what's that AllocateHwnd anyway? And why must it be thread-safe? As the Google is guick to tell (BTW, Steve, thanks for the search filter!), AllocateHwnd is used to create a hidden window which you can use to receive messages in non-windowed components. Of course, you can use it outside of any component to set up simple and easy messaging subsystem anywhere in your application. If you need more communication channels, just call AllocateHwnd many times. I won't bother you with the usage pattern - if you want to use AllocateHwnd and don't know how, use the search link above. You'll find many examples, including this one from DelphiDabbler, which Steve's searcher lists on the first place. An example of a very popular component using AllocateHwnd internally is Delphi's TTimer. That should answer the first question, but what about thread-safety? Well, many programmers use AllocateHwnd in threaded code to create hidden windows where messages are processed. Many are also using TTimer inside threads without knowing the first thing about AllocateHwnd. But almost nobody knows that this is totally unsafe and may lead to rare and obscure crashes. AllocateHwnd was written with single-threaded VCL applications in mind and you can use it from a thread only if you take special precaution. Why is AllocateHwnd dangerousLet's see how the AllocateHwnd is implemented. Following code was copied from D2007's Classes.pas (in very old Delphis, AllocateHwnd was implemented in Forms.pas): var Basically, the code registers window class if necessary, creates a new window of that class, and sets window procedur for that window to MakeObjectInstance(Method). Nothing special, except this last step. Can you tell why it is necessary at all? The reason lies in the discrepancy between Delphi's object model and Win32 API, which is not object oriented. The TWndMethod parameter passed to the AllocateHwnd is not just an address of code, but contains also the address of the object this method belongs to. On the other hand, Win32 API wants to call a simple method anytime it has to deliver a message to a window. MakeObjectInstance bridges this gap. It manages a linked list of methods together with a dynamically generated code preamble (address of which is returned from the MakeObjectInstance function). When Windows calls this code preamble, it makes sure that correct method is called on the correct object. MakeObjectInstance is complicated, but it works. That is, until you call it from two threads at the same time. You see, MakeObjectInstance does nothing to lock its internal list while it is being manipulated. If you do this from two threads running on two CPUs, or even if you have only one CPU and context switch occurs at a bad time, internal instance list can get corrupted. Later, this may lead to crashes, bad program behaviour, you name it. And you'll never find the true culprit. Admittedly, there is only a small window - few instructions - which are problematic. In most applications such problems will never occur. But if you're running 24/7 server which calls AllocateHwnd/DeallocateHwnd constantly from multiple threads, you can be sure that sooner or later it will crash. SolutionThere are two possible solutions to the problem - one is to wrap all AllocateHwnd and DeallocateHwnd in some sort of critical section, spinlock or mutex that will allow only one instance to be called at the same time and other is to write a better and thread-safe AllocateHwnd. First solution is somewhat clumsy to implement in production code while the second can be hard to write. Actually, I search the net wide and deep and found only two alternative AllocateHwnd implementations (references below). I'm sure there are more. I just couldn't find them. None of them was really suitable for my needs so I created a third one using ideas from both of them. My version — DSiAllocateHwnd, DSiDeallocateHwnd and TDSiTimer — has been published as a part of the DSiWin32 library. This is the current version of my AllocateHwnd alternative:const There are many differences between this code and Delphi version.
I admit that this approach to message dispatching is slower than the Delphi's version, but usually that is not a problem - custom windows are usually created to process some small subset of messages only. AcknowledgmentsThe AllocateHwnd problem is not something I have found by myself. It has been documented for years, but is not well known. I'd like to thank to:
|
6 Comments:
Technical nit: cbWndExtra would be 8 (SizeOf(TMethod)), not the 4 that you mention in your final set of bullets. (The code pointer is 4 bytes, and the data pointer is another 4 bytes.)
None of this helps if you call code that calls the stock APIs, like TTimer or code that uses TTimer.
It might just be time to nag CodeGear into fixing it properly! Then it would be fixed once and for all.
Easy enough - only use the critical section when the multithreaded flag is set to true to prevent unneeded trips into the OS for single threaded Apps.
Glad you're using it! Thanks for the link. Great post btw. Can you get this into QC?
@joe: Of course. Stupid mistake. Sometimes I don't know how big my pointers are. :(
@xepol: Very true.
@steve: Indeed, I should add this to the QC. Will do so today.
About deallocate see this: http://delphi.about.com/od/windowsshellapi/l/aa093003c.htm
procedure *****.DeallocateHWnd(Wnd: HWND);
var
Instance: Pointer;
begin
Instance := Pointer(GetWindowLong(Wnd, GWL_WNDPROC));
if Instance <> @DefWindowProc then
// make sure we restore the old, original windows procedure before leaving
SetWindowLong(Wnd, GWL_WNDPROC, Longint(@DefWindowProc));
FreeObjectInstance(Instance);
DestroyWindow(Wnd);
end;
@lucefer: I have no idea what information you're trying to convey.
Post a Comment
Links to this post:
Create a Link
<< Home