INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Jobs

Delphi Multithreading

How do I thread-protect an object? by djjd47130
Posted: 2 Mar 13 (Edited 9 Oct 13)

There are many ways to thread-protect objects, but this is the most commonly used method. The reason you need to thread-protect objects in general is because if you have more than one thread which needs to interact with the same object, you need to prevent a deadlock from occuring. Deadlocks cause applications to freeze and lock up. In general, a deadlock is when two different threads try to access the same block of memory at the same time, each one keeps repeatedly blocking the other one, and it becomes a back and forth fight over access.

Protection of any object(s) begins with the creation of a Critical Section. In Delphi, this is TRTLCriticalSection in the Windows unit. A Critical Section can be used as a lock around virtually anything, which when locked, no other threads are able to access it until it's unlocked. This ensures that only one thread is able to access that block of memory at a time, all other threads are blocked out until it's unlocked.

It's basically like a phone booth with a line of people waiting outside. The phone its self is the object you need to protect, the phone booth is the thread protection, and the door is the critical section. While one person is using the phone with the door closed, the line of people has to wait. Once that person is done, they open the door and leave and the next comes in and closes the door. If someone tried to get in the phone booth while someone's using the phone, well, it's obvious that would lead to a fight. That fight would be a deadlock.

It is still a risk to cause a deadlock even when using this method, for example, someone trying to use the phone when someone else is using it. If for any reason a thread attempts to access the object without locking it, and while another thread is accessing it, you will still run into issues. So, you need to use this protection EVERYWHERE that could possibly need to access it. Remember, when you lock this, nothing else is able to lock it again (under the promise that all other attempts would also be using this same Critical Section). The locking thread must unlock it before it can be locked again.

Okay, so into the code. The four calls you will need to know are:

  • InitializeCriticalSection() - Creates an instance of a Critical Section
  • EnterCriticalSection() - Engages the lock
  • LeaveCriticalSection() - Releases the lock
  • DeleteCriticalSection() - Destroys an instance of a Critical Section
First, you need to declare a Critical Section somewhere. It's usually something that would be instantiated for the entire duration of the application, so I'll assume in the main form.

CODE

TForm1 = class(TForm)
  private
    FLock: TRTLCriticalSection; 

Then, you need to initialize (create) your critical section (presumably in your form's constructor or create event)...

CODE

InitializeCriticalSection(FLock); 

Now you're ready to use it as a lock. When you need to access the object it's protecting, you enter the critical section (locking it)...

CODE

EnterCriticalSection(FLock); 

Once you have done this, it is locked. No other thread other than the calling thread is able to access this lock. Remember, technically other threads are able to access the object (but would potentially cause a deadlock), so make sure all other threads are also first trying to lock it. That's the goal of this lock.

Once you have done everything you need in this thread, you leave the critical section (unlocking it)...

CODE

LeaveCriticalSection(FLock); 

Now, it is unlocked and the next thread which may have attempted a lock is now able to completely lock it. That's right, while a critical section is locked, it remembers any other lock attempt, and once the calling thread unlocks it, the next one in the queue automatically acquires this lock. Same concept as a line of people waiting outside a phone booth.

When you're all finished with the object, make sure you dispose of this critical section (presumably in your form's destructor or destroy event)...

CODE

DeleteCriticalSection(FLock); 

And those are the fundamentals. But we're not done yet.

It's highly advised that you should always use a try..finally block when entering/leaving a critical section. This is to ensure that it gets unlocked, in case of any unhandled exceptions. So, your code should look something like this:

CODE

EnterCriticalSection(FLock);
try
  DoSomethingWithTheProtectedObject;
finally
  LeaveCriticalSection(FLock);
end; 

Now, the last thing you may wish to do is wrap this up in a nice simple class to do the work for you. This way, you don't have to worry about all the long procedure names whenever you use this lock. This object is called TLocker, which protects an object instance for you. You would need to create an instance of this for every object instance you need to protect. So, instead of declaring something like FMyObject: TMyObject; you would do it like FMyObject: TLocker; and then give the object instance to it upon its creation.

CODE

type
  TObjectClass = class of TObject;
  
  TLocker = class(TObject)
  private
    FLock: TRTLCriticalSection;
    FObject: TObject;
  public
    constructor Create(AObjectClass: TObjectClass); overload;
    constructor Create(AObject: TObject); overload;
    destructor Destroy;
    function Lock: TObject;
    procedure Unlock;
  end;

constructor TLocker.Create(AObjectClass: TObjectClass);
begin
  InitializeCriticalSection(FLock);
  FObject:= AObjectClass.Create;
end;

constructor TLocker.Create(AObject: TObject);
begin
  InitializeCriticalSection(FLock);
  FObject:= AObject;
end;

destructor TLocker.Destroy;
begin
  FObject.Free;
  DeleteCriticalSection(FLock);
end;

function TLocker.Lock: TObject;
begin
  EnterCriticalSection(FLock);
  Result:= FObject; //Note how this is called AFTER the lock is engaged
end;

procedure TLocker.Unlock;
begin
  LeaveCriticalSection(FLock);
end; 

The first constructor TLocker.Create(AObjectClass: TObjectClass); expects a class type to be specified (such as TMyObject).

The other constructor TLocker.Create(AObject: TObject); expects an instance of an object already created. Bear in mind that if you do use this constructor, you should no longer refer directly to that object after passing it into this constructor.

In both of these cases, your object which is being protected will be automatically free'd when the TLocker is free'd.

Let's assume the second constructor of the two. Once you've created an instance of this class with your initial actual object reference, never reference to the actual object again. Instead, whenever you need to use that object, pull it out of the TLocker instance by locking it. Using a try..finally block, make sure you also unlock it once you're done, or else the lock is stuck.

So, using the class above, you can access an object like this:

CODE

procedure TForm1.FormCreate(Sender: TObject);
var
  O: TMyObject;
begin
  O:= TMyObject.Create;
  FMyObjectLocker:= TLocker.Create(O);
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  FMyObjectLocker.Free; //Your original object will be free'd automatically
end;

procedure TForm1.DoSomething;
var
  O: TMyObject;
begin
  O:= TMyObject(FMyObjectLocker.Lock);
  try
    O.DoSomething;
    
    //etc...

  finally
    FMyObjectLocker.Unlock;
  end;
end; 

As you see, I acquire the object at the same time as locking it. This should be the only possible way to access this object. Just make sure you always unlock it when you're done. Notice also how I also don't define the actual protected object in the class - to prevent accidental direct calls to the object.

Back to Embarcadero: Delphi FAQ Index
Back to Embarcadero: Delphi Forum

My Archive

Resources

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close