So far we’ve looked at creatingTThreaddescendants as the way to get code to run in a separate thread. But what if you just have a small chunk of code that you want to run in a thread and don’t want to go to the trouble of creating a whole new thread class to run it?
TThreadprovides three class methods that let you execute code in the context of a thread, without having to actually create a thread descendant.
The first class method we’ll look at is TThread.CreateAnonymousThread. This method will take the anonymous method that you pass to it, create a separate thread, execute the anonymous method, and then clean everything up for you. It’s a straight-forward, easy way to execute some code in a separate thread.
Let’s create another VCL form that looks like this:
Double click on the first button, and add the following code:
procedure TForm50.Button1Click(Sender: TObject);
Memo1.Lines.Add('All Done from an Anonymous thread');
end);
end).Start;
end;
The first thing you’ll notice is that CreateAnonymousThread takes an anonymous method as its only parameter. Then, it calculates how many prime numbers there are below 150,000. Then it uses the second class method we’ve seen –Synchronize– to write out the information to the memo. Notice that the prime calculations are happening outside of theSynchronizecall. (We’ll discuss theSynchronizecall below.) If you run this app, the prime number calculations will take some time. You should note, though, that the form remains responsive because the code is running in the context of a separate thread. You can move the form around as the calculations are being done.
Queue and Synchronize
The two other class methods that are available – and commonly used, I should add – are Queue and
Synchronize. Both are usually used to coordinate events in the context of another thread, as we saw above.
During the coming chapters on the Parallel Programming Library, you’ll see them used all the time. Generally, they are used to coordinate the processing of background threading code with the main thread. For instance, consider this code from theOnClickof the second button on our form:
procedure TForm50.Button2Click(Sender: TObject);
Memo1.Lines.Add('All done from the Synchronize class procedure'\
);
end);
end;
TheSynchronizecall takes two parameters. One is the thread whose context will run the code, and then an anonymous method to run the code itself. In this case, there isn’t a lot of point in doing what we are doing here, because the anonymous method ends up being run on the current – in this case main – thread. If you
run the application and then press the second button, you’ll notice that the code runs, but the application itself is not responsive because the code is running in the context of the main thread. The same happens when we useQueueinstead ofSynchronize.
procedure TForm50.Button3Click(Sender: TObject);
var
LTotal: integer;
begin
TThread.Queue(TThread.CurrentThread, procedure begin
LTotal := PrimesBelow(150000);
Memo1.Lines.Add('Total: ' + LTotal.ToString);
Memo1.Lines.Add('All Done from the Queue class procedure');
end);
end;
Queue vs Synchronize
We’ve seen the similar uses ofQueueandSynchronize, and by now you are no doubt asking, “When should I use one or the other?” The quick answer is that you should almost always useQueue.
The longer answer is that you should avoidSynchronizebecause it always suspends the operation of the current thread to run the code in its anonymous method. If there are two or more activeSynchronizecalls, they will all block the main thread and be called in a serialized fashion. This doesn’t sound like something you’d necessarily want to have happen, especially the blocking part.
Instead, it is better to queue the requests up and do them one at a time. Thus, the call toQueueis generally preferable.Queuesubmits a request to the main thread and returns immediately. When the main thread is out of work/idle, it will check for any pending requests and execute the associated anonymous method.
Synchronizedoes the same but waits until the main thread has executed the anonymous procedure before returning.
Synchronization
So far, we’ve only looked at single threads running in parallel to the main thread. We haven’t had to worry too much about coordinating things between threads. As you can imagine, however, such a thing is pretty important.
Threads can share data and when they do, there is a danger of them trying to access that shared data at the same time, at different times, and at unpredictable times.
Again, this is the reason that the VCL can’t be made thread-safe. It shares data prolifically, and all the thread synchronization that would have to take place would make the VCL slow to a snail’s pace.
Thus, we must have a way to allow for the safe reading and writing of shared data.
Synchronization Classes
When you do multi-threaded programming, you will very often have to share data between threads. In order to do that, you have to synchronize the running of those threads in order to safely access that common data.
When you synchronize two threads, you are really asking that one thread be given access to the shared resource to the exclusion of all others. In other words, you are serializing access to that resource.
Therefore, you should endeavor to synchronize as little as possible, as any synchronization in effect defeats the parallel nature of threading. However, synchronization is necessary. Without careful and proper synchronization, your application can have unpredictable results and even end up in a frozen state. And that’s bad.
Therefore, the Delphi RTL provides a number of different ways to synchronize threads, each with their own way of doing things and each with their own advantages and disadvantages. While there are no code examples here in the chapter for each of these synchronization types, the code in the book’s repository does include an example application that uses each of these techniques to protect a common resource.
TCriticalSection
Probably the most basic synchronization technique is the critical section. A critical section provides an exclusive place for your code to run, where no other thread can intrude. You canEntera critical section, run your code and thenLeave. Other threads can still be running, but only one thread at a time can be inside of a critical section, and thus code within a critical section is thread-safe.
If Thread A enters a critical section and Thread B tries to enter, it will be blocked until Thread A leaves.
Because other threads may be blocked when you enter a critical section, your critical sections should be short and to the point.
In addition, critical sections can be recursive – that is, if a thread is inside a critical section, it can actually enter that critical section again. Of course, this means that the thread must leave the thread the same exact number of times it enters.
Critical sections are part of the Win32/64 API, but of course, Delphi doesn’t leave you high and dry – the RTL providesTCriticalSection, which is a nice encapsulation of a critical section.TCriticalSectionis even cross-platform, functioning the same on all the platforms that Delphi supports.TCriticalSectioncan be found in theSystem.SyncObjsunit.
However, as a general notion, rather than as a specific implementation, there are a number of ways to provide protection to code running in the context of multiple threads. I can’t recommend one over the other, as they all provide the same basic functionality but with different purposes.
TMonitor
TheTMonitorclass is another way to synchronize threads, operating in a very similar manner to TCrit-icalSection.TMonitoris declared in theSystemunit, and operates on the notion of a token object. You create an object – any object will do – and then pass that object toTMonitor. The token object can then be locked and unlocked in order to provide protection for code within the lock.
TInterlocked
We saw the use of TInterlocked above to safely increment a shared integer between threads without locking. It does a number of other functions in a thread-safe, lock-less manner, including incrementing and decrementing variables, adding to a variable, and safely exchanging the values of two variables. All of TInterlocked’s operations are atomic, meaning that they can be treated as a single operation for the purpose of multi-threading code.
UseTInterlockedfor doing simple operations like incrementing or decrementing integers. You’ll find that it is easier than using a critical section or some other synchronization techniques for simple math operations and certainly more performant than other locking techniques.
TMutex
A mutex is a construct that provides a MUTually EXclusive mechanism. Mutexes are designed to be like a baton in a relay race – only one process can have the baton at a time. Thus, only one thread can have access to the mutex at a given time, and so it can be used to protect code that needs to run in a thread-safe manner.
Mutexes are created with and then referred to by a specific name. They are also cross-process and can be used to protect resources between multiple applications. As a result they are slower than a critical section.
TEvent
TEventis a class in theSystem.SyncObjsunit that allows you to signal a thread that an event has occurred.
Often, you’ll want a thread to either wait until something specific happens or execute until that something happens. Either way, aTEventcan be used to send that signal to either stop or start a thread executing. They don’t force mutual exclusion; rather, they send signals to let threads know how they should behave.
As Martin Harvey points out in hisexcellent threading article²³, events are like a stoplight – they are either red or green, and they either make you stop or let you move ahead. An event is a marvelous way of letting a thread sleep and take no CPU at all, then be woken when a condition fires. It’s a great way to write CPU-efficient, and cleanly designed, code.
For instance, you may have a set of threads that you want to run, and you want to know when they are all finished. You can pass aTEventto each of the threads, and mark each thread as “green”, and then when the thread is done, mark the TEventas “red”. You then can use the TEvent.WaitForMultiplecall to check all the threads and know when they are all terminated. The code on BitBucket that accompanies this book contains a demo calledEventDemo.exethat shows this very technique.
A TEventcan be named, like aTMutex, in which case it can be used to communicate between processes.
However, for use within a single process, it’s preferable to use events without a name (anonymous events).
TSpinLock
A spinlock is a thread synchronizer that operates on the notion that there is a certain amount of overhead to starting and stopping the execution of a given thread. Think of a car coming to a stoplight. It would be a certain amount of overhead if every time you came to a red stop light, you stopped and turned off your car.
²³http://www.nickhodges.com/MultiThreadingInDelphi/toc.html
Then, when the light turns green, you’d have to start up your car again before proceeding. This is similar to the notion of a thread stopping at a critical section. A spinlock is a synchronization technique that would be the equivalent of leaving your car running at a stoplight – it lets the thread “spin” rather than actually come to a halt while the critical section of code is executed.
Delphi providesTSpinLockto encapsulate the notion of a spinlock. Spinlocks should be used in instances of very high concurrency when performance is critical – i.e., when the wait is likely to be very short, and the overhead of actually coming to a complete stop doesn’t make sense. The “spinning” consumes CPU cycles, and thus can prevent other threads from running. Therefore, it should be used with care. Unless you have a very specific reason for usingTSpinLock, I’d recommend leaving it alone.
TMultiReadExclusiveWriteSynchronizer
Wow, that’s a mouthful. Let’s call it TMREWSfor short. TMREWS is another synchronization technique that should be used in a specific situation: when you expect that the given shared resources within it will be read from many more times than it will be written to.TMREWS will grant a lock as long as no one is trying to write to the protected resource. If you need to write to the resource, thenTMREWSwill block all reads until the writing is done. If you need to read the resource, any number of threads can do so as long as no one is trying to write to the resource. For that reason,TMREWSimplements the following interface, which provides all the functionality that you need fromTMREWS. You should prefer the use of the interface over a reference to the class itself:
type
IReadWriteSync = interface
['{7B108C52-1D8F-4CDB-9CDF-57E071193D3F}']
procedure BeginRead;
procedure EndRead;
function BeginWrite: Boolean;
procedure EndWrite;
end;
As you can see, the interface allows you to choose whether you are going to read or write to the shared resource.
Remember, useTMREWSwhen reading is much more common that writing.