{"id":1925,"date":"2013-10-16T18:49:54","date_gmt":"2013-10-16T06:49:54","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=1925"},"modified":"2013-10-16T18:49:54","modified_gmt":"2013-10-16T06:49:54","slug":"vcl-threading-synchronization","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/1925\/","title":{"rendered":"VCL Threading – Synchronization"},"content":{"rendered":"[Estimated Reading Time: <\/span> 6<\/span> minutes]<\/span><\/span>

Although I am using Oxygene<\/strong> a lot these days, Delphi remains my tool of choice for Win32 (and x64) development, together with the VCL.<\/p>\n

Hence this post.<\/p>\n

A long time ago, in a galaxy far far away, Delphi was a Windows only development tool. 16 was the number of the bits with which it was concerned, and 1 was the number of threads in the process (though it was not called a thread).<\/p>\n

It was a simpler time.<\/p>\n

Then the bits were doubled and the number of threads did multiply, but it was important still that some things happened only on the original thread, though for a time a blinded eye could be turned since – no matter the plurality of threads – with only one piece of silicon to share, only one thread could be running at any one time.<\/p>\n

Yet lo, TThread.Synchronize()<\/strong> was conceived.<\/p>\n

<\/p>\n

No More Inner Verity<\/h2>\n

Ok, that’s enough faux-k lore type language. Back to proper English. \ud83d\ude42<\/p>\n

As anyone that ever did multi-threading in those glory days will (or should) tell you, the Synchronize()<\/strong> mechanism had problems rights from the start, especially if you managed to get your hands on a PC with more than one actual<\/em> CPU. You quickly learned to avoid it like the proverbial.<\/p>\n

Those problems were eventually fixed I believe, but by then I had learned to use other techniques and it remained a relatively complex mechanism for achieving what was – on Windows<\/strong> – mostly achievable by far simpler means. Remember, it was not a general purpose thread synchronization mechanism. The sole purpose of Synchronize()<\/strong> was to ensure that some specified method was performed on the application main thread, sometimes referred to as the “VCL thread” because it was primarily where your VCL UI code would run.<\/p>\n

These days of course, the Delphi TThread<\/strong> class finds itself co-opted into a role for which it was never originally designed: a cross-platform abstraction of whatever threading capabilities exist on the various supported platforms, with a concomitant explosion in complexity of the class (in terms of trying to understand it from perusing the source at least).<\/p>\n

Of course, the “VCL thread” per se doesn’t exist in this new world order, since the VCL remains planted firmly in Windows soil, with TThread<\/strong> serving both masters – VCL and the other guy. You know of whom I speak: Bit of a chimp. With a tendency toward combustion. \ud83d\ude09<\/p>\n

But back to Windows<\/strong>.<\/p>\n

If you are working on code that is similarly firmly planted in Windows<\/strong>, Synchronize()<\/strong> is massively over-engineered for the purpose it serves. Especially when you consider that Windows<\/strong> already provides a reliable and efficient mechanism for passing control from one thread to another synchronously.<\/p>\n

That mechanism is messaging<\/strong>.<\/p>\n

I Send a Message<\/h2>\n

Messages in Windows<\/strong> can be post<\/strong>ed (asynchronously) or send<\/strong>ed [sic] (synchronously).<\/p>\n

If a thread uses SendMessage()<\/code> to send a message to a window created on some other thread, the synchronous behaviour is maintained by Windows<\/strong> itself, which will manage the business of suspending the calling thread, processing the message on the thread of the recipient window, and then returning the result to the calling thread.<\/p>\n

When you simply wish to notify the main (VCL) thread of some event, this is perfect and – with a bit of additional work – can be extended to pass whatever additional data about that event you wish.<\/p>\n

I have created a class which provides the basis for just such a mechanism, where-ever I may need it. Typically this is in some library function which involves creating a worker thread but which supports some sort of VCL thread callback mechanism.<\/p>\n

The threading aspects of the implementation are entirely transparent to the consumer of the library function, including the message handling device.<\/p>\n

As an example, I shall show the key aspects of a thread implementation calling an event with a string parameter, where that event is to be handled in the VCL thread.<\/p>\n

The signature of the event that will be supported will be:<\/p>\n

\r\n  type\r\n    TStringEvent = procedure(const aString: String) of object;\r\n<\/pre>\n
This is the only aspect of this mechanism that needs to be exposed in the interface of my library unit.  The rest is implementation detail that the consumer of that library code need not be concerned with.<\/p>\n
Message Handler Implementation<\/h2>\n
First of all, the mechanism I implemented requires that I derive a class from a TMessageHandler<\/strong> base (which I shall cover in a later post).  This is the intermediary that will translate Windows<\/strong> messages sent from my thread(s) into the event notifications supported by those threads.<\/p>\n
In this case there is just one message involved.  I implement a method to receive and process that message in the VCL thread, and a corresponding method to be called by the thread wishing to send that message.<\/p>\n
Also, a single instance of this particular message handler will cater for all threads that might be involved.  Everything that the handler will need to translate messages into VCL events will be delivered via the messages themselves, so the declaration of the handler is very simple:<\/p>\n
\r\n  const\r\n    MSG_OUTPUT = WM_USER;\r\n\r\n  type\r\n    TOutputHandler = class(TMessageHandler)\r\n      procedure Output(var aMessage: TMessage); message MSG_OUTPUT;\r\n      procedure SendOutput(const aThread: TMyThread; const aString: String);\r\n    end;\r\n<\/pre>\n
An instance of this handler must be created in the VCL thread context in order to function correctly (compliance with this is ensured via assertions in the TMessageHandler<\/strong> base class).  The simplest way to ensure this is to create the handler in unit initialization<\/strong> (and destroy it in finalization<\/strong>):<\/p>\n
\r\n\r\n  var\r\n    _OutputHandler: TOutputHandler;\r\n\r\ninitialization\r\n  _OutputHandler := TOutputHandler.Create;\r\n\r\nfinalization\r\n  _OutputHandler.Free;\r\nend.\r\n<\/pre>\n
Remember, all of this is safely tucked away in the implementation of my unit.  _OutputHandler<\/strong> is a unit implementation variable, sometimes (incorrectly imho) called a “global”.  The leading underscore in the name is my personal convention in such cases.<\/p>\n
The implementation of the methods on the handler class are straightforward.  First, sending the message:<\/p>\n
\r\n  procedure SendOutput(const aThread: TMyThread; const aString: String);\r\n  begin\r\n    SendMessage(MSG_OUTPUT, Integer(aThread), Integer(PChar(aString)));\r\n  end;\r\n<\/pre>\n
The protocol for this message is that a reference to the sending thread is passed in WParam<\/strong> with a pointer to the string for the event in LParam<\/strong>.<\/p>\n
NOTE:<\/strong> This code was originally written for 32-bit Windows<\/strong> and I have not yet gone through it to address any potential 64-bit<\/strong> issues deriving from the packaging of pointers in message WParam<\/strong> and LParam<\/strong>.  There may not be any or there may be plenty.  I simply haven’t needed to consider it yet<\/em><\/p>\n
These params are then unpacked and used to invoke the target event handler in the message processing method:<\/p>\n
\r\n  procedure TOutputHandler.Output(var aMessage: TMessage); \r\n  var\r\n    thread: TMyThread;\r\n    event: TStringEvent;\r\n    ptr: PChar;\r\n    str: String;\r\n  begin\r\n    thread  := TMyThread(aMessage.WParam);\r\n    event   := thread.OutputEvent;\r\n\r\n    ptr := PChar(aMessage.LParam);\r\n    str := ptr;\r\n\r\n    event(str);\r\n  end;\r\n<\/pre>\n
The steps here are laid out plainly so that each step can be followed clearly.<\/p>\n
Each thread that potentially uses this handler will have an event handler that it wishes to be used.  A reference to this event handler is maintained on the thread itself so the first thing that the message handler must do is extract the thread reference from the WParam<\/strong>, and from that obtain the target event handler.<\/p>\n
Next, the string to be sent with the event is passed in the LParam<\/strong>.  Or rather, a pointer to the string.  So LParam<\/strong> is first cast as PChar<\/strong> and then assigned to a local String<\/strong> variable.<\/p>\n
With the target event<\/strong> and str<\/strong>ing in hand, the message handler can then simply call the event, passing that string.<\/p>\n
All of this occurs in the context of the VCL thread<\/strong>.<\/p>\n
For an instance of TMyThread<\/strong> to send a string event to the assigned event handler all it has to do is call the SendOutput()<\/strong> method of the _OutputHandler<\/strong> unit variable:<\/p>\n
\r\n  procedure TMyThread.Execute;\r\n  var\r\n    s: String;\r\n  begin\r\n    while NOT Terminated do\r\n    begin\r\n      \/\/ ...\r\n\r\n      _OutputHandler.SendOutput( self, s );\r\n\r\n      \/\/ ...\r\n    end;  \r\n  end;\r\n<\/pre>\n
Less Is More<\/h2>\n
This is obviously not a general purpose synchronization mechanism and it is “more complicated” than simply using Synchronize()<\/strong> in the sense that it involves implementing a specific message handler class (which is, in essence, a message marshalling class).<\/p>\n
But the mechanism that underpins your custom handlers is very simple.  The TMessageHandler<\/strong> class consists of very little code, most of which simply ensures correct usage rather than “doing” anything itself.  The behaviour of your callbacks is also very easily understood – callbacks are scheduled for processing just like any other message.<\/p>\n
They arrive on and are dispatched from your application message queue just like every other (Windows message based) event that your application has to deal with.<\/p>\n
This does create a marked difference between this mechanism and Synchronize()<\/code>.<\/p>\n
With TThread.Synchronize()<\/code> exceptions raised by\/escaping from the synchronized method will propagate back to the calling thread and (usually) must be handled by the thread.<\/p>\n
Exceptions raised during the execution of event handlers invoked by my message handler mechanism propagate not to the calling thread but to the application message loop<\/em>.  Unless you handle them in the event handler itself, they will be deemed “unhandled” and your application default exception handler will be invoked.<\/p>\n
However, I regard this difference as another advantage<\/em> of the message based mechanism.<\/p>\n
It makes implementing a thread-callback event no different than, say, implementing a Button.OnClick()<\/strong> event on a form and more often than not, this is exactly as it should be.<\/p>\n
Coming Next…<\/h3>\n
Next time I shall look at another threading technique, this time involving asynchronous processes of indeterminate lifetime which may expire naturally or require express termination.<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span> 6<\/span> minutes]<\/span><\/span> Although I am using Oxygene a lot these days, Delphi remains my tool of choice for Win32 (and x64) development, together with the VCL. Hence this post. A long time ago, in a galaxy far far away, Delphi was a Windows only development tool. 16 was the number of the bits with which it was […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[4],"tags":[292,194,243,16,93,14],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-v3","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":1930,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1930\/","url_meta":{"origin":1925,"position":0},"title":"VCL Threading – Indeterminate Lifetimes","date":"18 Oct 2013","format":false,"excerpt":"Sometimes when you launch a thread you don't know when it will complete whatever processing it is tasked with. Sometimes you do. Sometimes it may never complete and will require that you expressly terminate it. Usually any given thread will have a lifecycle that is at least consistently one or\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1330,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1330\/","url_meta":{"origin":1925,"position":1},"title":"Of Threads, Stacks and RAM – Part 2","date":"29 Nov 2012","format":false,"excerpt":"In the previous post in this series, we saw that the number of threads that a given process could support was determined by a number of factors, of which the stack size reserved for each thread was key. We also saw how we could change the stack size used by\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":807,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/807\/","url_meta":{"origin":1925,"position":2},"title":"Use Knowledge of Your Own Threads to Extract Optimal Performance…","date":"29 Sep 2011","format":false,"excerpt":"\"The Delphi Geek\" recently blogged about a performance bottleneck he had identified in FastMM when used with a particular conditional define. Although not directly related, his post reminded me of an experience I had many years ago, working on a highly complex multi-threaded system (long before FastMM) and the strategy\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1297,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1297\/","url_meta":{"origin":1925,"position":3},"title":"Of Threads, Stacks and RAM – Part 1","date":"28 Nov 2012","format":false,"excerpt":"Roberto Schneiders recently drew my attention to the first post on his new blog (which I can recommend as a good read :) ), presenting the results of some performance testing of DataSnap that he had been involved with which proved to be very interesting (if initially somewhat disappointing). But\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2012-11-28-at-20.24.21-.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":576,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/576\/","url_meta":{"origin":1925,"position":4},"title":"Commitment Issues","date":"06 Oct 2009","format":false,"excerpt":"No, not a relationship blog and no, not a rant about the relationship between Embarcadero and the Delphi community. \u00a0This is a strictly and purely technical post about what \"Committed\" means in terms of Windows memory, and in particular a key aspect of how that applies to threaded applications. Last\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2118,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2118\/","url_meta":{"origin":1925,"position":5},"title":"Creation Stories","date":"07 Nov 2013","format":false,"excerpt":"In the beginning there was The Word a HWND. But not all gifts of creation can be relied upon, as I just learned. Or rather, remembered. As regular readers will know, I am currently polishing up my Smoketest framework for release (don't worry, this post won't take long and then\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Very-Pretty.gif?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1925"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=1925"}],"version-history":[{"count":7,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1925\/revisions"}],"predecessor-version":[{"id":1936,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1925\/revisions\/1936"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=1925"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=1925"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=1925"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}