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 :-)
Allen,
ReplyDeleteHave you seen this? http://tinyurl.com/39sbkk
I hope the name for that feature will change in time for release. We already got a Forms.TMonitor thank you very much. :)
ReplyDeleteDear, Allen
ReplyDeleteIt 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}.
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:
ReplyDeleteSelf.Monitor.Enter
twm
If the purpose of your blog is to make customers long for the next release --> mission accomplished :-)
ReplyDeleteAMD Accelerates Application Development with Inaugural Release of Open Source Performance Library:
ReplyDeletehttp://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..."
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.
ReplyDelete"Gee, Forms.pas already includes a TMonitor class that holds information about a display monitor."
ReplyDeleteI'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.
how about TSyncMonitor?
ReplyDeleteI have found very nice looking parallel library for delphi:
ReplyDeletehttp://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.
This looks very promising :) I can't wait to see how this will be when Tiburon is released.
ReplyDeleteGreat to see the multithreading / paralell programming supporting being spiffed up!
ReplyDeleteWe 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
<>
ReplyDeleteIOW, an interface. This is great. Good move.
"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)"
ReplyDeleteIOW, an interface. This is great. Good move.
"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."
ReplyDeleteYou can avoid this by giving TObject an IMonitor interface. If a programmer need to avoid name collisions further down the heirarchy, he can do so with the "implements" directive.
-d
Allen, will TApplication, TScreen and TForm ever be thread-safe? I mean, when will we finally be able to create forms in separate threads, having their own modal stack, etc?
ReplyDelete