Lock my Object… Please!
Here’s a quick recap of all the DPL (Delphi Parallel Library) related posts over the last few months:
A Critical[Section] Difference: Windows XP vs. Windows Vista
Breaking the rules
Simmering Unicode, bring DPL to a boil (Part 2)
Simmering Unicode, bring DPL to a boil
Placing your code in the forge - Refining a technique
When code lies - A better solution
Stupid Enumerator Tricks - And now for something completely different
Magical Assembler Incantations - Nested functions and anonymous methods
The Life and Times of a Thread Pool
I cut and I cut and it was still too short!
Spot the deadlock
Wading in the shallow end of the pool - Thread Pools
As another follow on to my discussion of the TMonitor (see the above "Bring DPL to a boil" articles) things have changed a little. The TMonitor class is no longer a separate class that you can create and use. It is now tied directly to any TObject instance or derivative (which means any instance of a Delphi class). There is still the notion of a TMonitor but only to serve as a way to tie together the "monitor" functionality. Rather than creating one and setting about to locking/unlocking it, you now only need an object instance. For Tiburón, you merely need to call System.TMonitor.Enter(<obj>); or System.TMonitor.Exit(<obj>); among the other related methods.
I’ve contemplated putting these methods directly on TObject itself, but there is the issue with calling these methods when a descendant class has a method of the same name. The code will compile and function normally due to Delphi’s scoping rules, but it could make it harder for users to call those methods in these cases. Thread synchronization should never be done lightly and should require some forethought and planning. A simple rule of thumb is that you should never call unknown code (or code that you’re not entirely sure where it goes and what it does) while holding a lock.
This now paves the way to add some interesting intrinsic functionality such as using this as the basis for "synchronized" methods or even synchronized code blocks similar to the C# lock keyword. While you’ve always been able to create an OS critical section, or use some of the helper classes in SyncObjs.pas, this new mechanism will be available on any object.
I merely design it then write about it… you get to kvetch 
Share This | Email this page to a friend
Posted by Allen Bauer on February 19th, 2008 under Parallel Programming, CodeGear, Delphi |13 Responses to “Lock my Object… Please!”
Leave a Comment
Server Response from: dnrh1.codegear.com
February 19th, 2008 at 9:06 am
It would still be useful to call functions in the context of another thread. Currently you can call in the context of the current thread or the main thread, but you have to do backflips to talk with another thread.
February 19th, 2008 at 11:55 am
Allen,
Have you seen this? http://tinyurl.com/39sbkk
February 19th, 2008 at 2:57 pm
I hope the name for that feature will change in time for release. We already got a Forms.TMonitor thank you very much.
February 19th, 2008 at 9:53 pm
Dear, Allen
It looks like using syncIdx field of object instance in .NET,
which exists in any instance of .NET object.
May be the best way is not to add any hidden field to Object instance in Delphi.
Just do it by compiler switch like
{$AUTOSYNC ON}.
February 19th, 2008 at 11:38 pm
Maybe, instead of cluttering the generic TObject namespace with many functions, which is a bad idea as you already noted, have a property Monitor (or something more descriptive) that exposes the TMonitor methods:
Self.Monitor.Enter
twm
February 20th, 2008 at 2:30 am
If the purpose of your blog is to make customers long for the next release –> mission accomplished
February 20th, 2008 at 5:48 am
AMD Accelerates Application Development with Inaugural Release of Open Source Performance Library:
http://www.amd.com/gb-uk/Corporate/VirtualPressRoom/0,,51_104_543~123872,00.html
"…It also offers aggressive internal threading features which manage sophisticated threading models to exploit multi-core and multiprocessor systems…"
February 20th, 2008 at 11:59 pm
Gee, Forms.pas already includes a TMonitor class that holds information about a display monitor. Perhaps (as other posts have already suggested) a more definitive name is in order.
February 21st, 2008 at 1:39 am
"Gee, Forms.pas already includes a TMonitor class that holds information about a display monitor."
I’d already considered that. The problem is that "Monitor" is also a very commonly accepted vernacular for this exact functionality. As a compromise, there are a set of global functions named something like "MonitorEnter();" or "MonitorTryEnter();"
Allen.
February 21st, 2008 at 10:15 pm
how about TSyncMonitor?
February 22nd, 2008 at 3:26 am
I have found very nice looking parallel library for delphi:
http://www.axon7.com/flx/news/?ItemId=18
After reading documentation, I can say this is what I need.
The only one thing that I do not like in this library is ParallelFor (they should use nested procedures instead of normal procedures to eliminate global variables).
I think CodeGear should at least consider to buy delphi part to incorporate this to next version of delphi if not take over whole company.
February 22nd, 2008 at 10:36 am
This looks very promising
I can’t wait to see how this will be when Tiburon is released.
March 7th, 2008 at 1:30 pm
Great to see the multithreading / paralell programming supporting being spiffed up!
We also need better support to efficiently wait for cross-thread signals in the main VCL thread, and general mechanisms to communicate between threads. Here is my 1999 article and code to target some of these:
http://hallvards.blogspot.com/2008/03/tdm6-knitting-your-own-threads.html