Threading in Delphi for .NET - Writing Thread-safe Code .NET Style
(Page 9 of 15 )
Writing a multithreaded application is pointless if multiple threads cannot interact in a predictable and bug-free manner. A body of code is said to be thread-safe if multiple threads can safely execute it without any side effects. One way of making a method or function thread-safe is to serialize access to it, thereby allowing only one thread to execute the code at a time.
Thread-safe code can be accomplished by following a few guidelines:
Avoid variables and objects shared between threads. If this is not feasible, use a locking mechanism to serialize access.
Use variables declared on the stack (for example, local variables).
Use stateless routines by passing in all parameters that are needed to do its work.
Use stateless methods, performing work on the internal data of the object. (This assumes that each object instance is only accessible from one thread.) Any additional data should be passed as parameters. Make sure that parameters or fields do not refer to other global data or unprotected objects.
Use thread local storage (threadvar), which is explained in a later section of this chapter.
Fortunately, the .NET Framework provides a rich collection of classes to help write thread-safe code. These classes are generalized as locking and event mechanisms. Locking performs serialization, whereas an event is used for communication between threads.
Locking Mechanisms
Serializing access to a resource is accomplished by using a locking mechanism. By only allowing one thread to enter into a protected region, other threads are locked out. When one thread exits a protected region of code, another thread is then allowed to enter it.
There are three locking mechanisms in the .NET Framework: mutexes, monitors, and Read-Write locks. In addition, the Interlocked class provides a basic set of operations that are atomic. Atomic operations are those that are guaranteed not to be interrupted once they begin.
The System.Threading.WaitHandle Class
Before discussing mutexes and monitors, it is necessary to begin with the WaitHandle class as these two locking mechanisms inherit common functionality from it. Listing 14.7 contains the definition of the WaitHandle class.
Listing 14.7 Declaration of the System.Threading.WaitHandle Class
System.Threading.WaitHandle = class (System.MarshalByRefObject, IDisposable)
public
constructor Create;
procedure Close; virtual;
function WaitOne: Boolean; overload; virtual;
function WaitOne(timeout: TimeSpan;
exitContext: Boolean) : Boolean; overload; virtual;
function WaitOne(millisecondsTimeout: Integer;
exitContext: Boolean) : Boolean; overload; virtual;
class function WaitAll(waitHandles: array of WaitHandle;
millisecondsTimeout: Integer;
exitContext: Boolean) : Boolean; overload; static;
class function WaitAll(waitHandles: array of WaitHandle;
timeout: TimeSpan;
exitContext: Boolean) : Boolean; overload; static;
class function WaitAll(waitHandles: array of WaitHandle) : Boolean;
overload; static;
class function WaitAny(waitHandles: array of WaitHandle;
millisecondsTimeout: Integer;
exitContext: Boolean) : Integer; overload; static;
class function WaitAny(waitHandles: array of WaitHandle;
timeout: TimeSpan;
exitContext: Boolean) : Integer; overload; static;
class function WaitAny(waitHandles: array of WaitHandle) : Integer;
overload; static;
property Handle: System.IntPtr read; write;
end;
Similar to the Win32 API WaitForMultipleObjects(), the overloaded WaitAll() method accepts multiple WaitHandle objects and will only return if all handles are signaled. The WaitAny() method returns if any of the multiple WaitHandle objects are signaled. Both methods have optional timeout parameters that enable the methods to exit the wait prematurely and avoid deadlocks.
 This chapter is from Delphi for .NET Developer's Guide, by Xavier Pacheco (Sams, 2004, ISBN: 0-672-32443-1). Check it out at your favorite bookstore today.
Buy this book now. |
Next: Mutex and Monitor Classes >>
More .NET Articles
More By Xavier Pacheco
