Lock my Object... Please!

Posted by on in Blogs

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 :-)

About
Gold User, Rank: 84, Points: 11

Comments

  • Guest
    Mark Andrews Tuesday, 19 February 2008

    Allen,

    Have you seen this? http://tinyurl.com/39sbkk

  • Guest
    Henrick Hellstr?m Tuesday, 19 February 2008

    I hope the name for that feature will change in time for release. We already got a Forms.TMonitor thank you very much. :)

  • Guest
    Sergey Antonov aka oxffff Tuesday, 19 February 2008

    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}.

  • Guest
    Thomas Mueller Tuesday, 19 February 2008

    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

  • Guest
    Giel Tuesday, 19 February 2008

    If the purpose of your blog is to make customers long for the next release --> mission accomplished :-)

  • Guest
    Kryvich Tuesday, 19 February 2008

    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..."

  • Guest
    Louis Kleiman Wednesday, 20 February 2008

    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.

  • Guest
    Allen Bauer Wednesday, 20 February 2008

    "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.

  • Guest
    DR Rd Thursday, 21 February 2008

    how about TSyncMonitor?

  • Guest
    Filip Borkowski Thursday, 21 February 2008

    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.

  • Guest
    Atle Smelvaer Friday, 22 February 2008

    This looks very promising :) I can't wait to see how this will be when Tiburon is released.

  • Guest
    Hallvard Vassbotn Friday, 07 March 2008

    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

  • Guest
    Dennis Landi Friday, 20 March 2009

    <>

    IOW, an interface. This is great. Good move.

  • Guest
    Dennis Landi Friday, 20 March 2009

    "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)"

    IOW, an interface. This is great. Good move.

  • Guest
    Dennis Landi Friday, 20 March 2009

    "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."

    You 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

  • Guest
    Márton Balassa Wednesday, 27 May 2009

    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?

  • Please login first in order for you to submit comments
  • Page :
  • 1