barcode printing vb.net A Potpourri of Hybrid Constructs in Visual C#

Drawer PDF-417 2d barcode in Visual C# A Potpourri of Hybrid Constructs

The FCL ships with many hybrid constructs that use fancy logic to keep your threads in user mode, improving your application s performance . Some of these hybrid constructs also avoid creating the kernel-mode construct until the first time threads contend on the construct . If threads never contend on the construct, then your application avoids the performance of creating the object and also avoids allocating memory for the object . A number of the constructs also support the use of a CancellationToken (discussed in 26, Compute-

Bound Asynchronous Operations ) so that a thread can forcibly unblock other threads that might be waiting on the construct . In this section, I introduce you to these hybrid constructs .

The first two hybrid constructs are System.Threading.ManualResetEventSlim and System.Threading.SemaphoreSlim . 2 These constructs work exactly like their kernel-mode counterparts except that both employ spinning in user mode and they both defer creating the kernel-mode construct until the first time contention occurs . Their Wait methods allow you to pass a timeout and a CancellationToken . Here is what these classes look like (some method overloads are not shown):

public class ManualResetEventSlim : IDisposable { public ManualResetEventSlim(Boolean initialState, Int32 spinCount); public void Dispose(); public void Reset(); public void Set(); public Boolean Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken); public Boolean IsSet { get; } public Int32 SpinCount { get; } public WaitHandle WaitHandle { get; } } public class SemaphoreSlim : IDisposable { public SemaphoreSlim(Int32 initialCount, Int32 maxCount); public void Dispose(); public Int32 Release(Int32 releaseCount); public Boolean Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken); public Int32 CurrentCount { get; } public WaitHandle AvailableWaitHandle { get; } }

Probably the most-used hybrid thread synchronization construct is the Monitor class, which provides a mutual-exclusive lock supporting spinning, thread ownership, and recursion . This is the most-used construct because it has been around the longest, C# has a built-in keyword to support it, the just-in-time (JIT) compiler has built-in knowledge of it, and the common language runtime (CLR) itself uses it on your application s behalf . However, as you ll see, there are many problems with this construct, making it easy to produce buggy code . I ll start by explaining the construct, and then I ll show the problems and some ways to work around these problems .

While there is no AutoResetEventSlim class, in many situations you can construct a SemaphoreSlim object with a maxCount of 1 .

Every object on the heap can have a data structure, called a sync block, associated with it . A sync block contains fields similar to that of the AnotherHybridLock class that appeared earlier in this chapter . Specifically, it has fields for a kernel object, the owning thread s ID, a recursion count, and a waiting threads count . The Monitor class is a static class whose methods accept a reference to any heap object, and these methods manipulate the fields in the specified object s sync block . Here is what the most commonly used methods of the Monitor class look like:

public static class Monitor { public static void Enter(Object obj); public static void Exit(Object obj); // You can also specify a timeout when entered the lock (not commonly used): public static Boolean TryEnter(Object obj, Int32 millisecondsTimeout); // I ll discuss the lockTaken argument later public static void Enter(Object obj, ref Boolean lockTaken); public static void TryEnter(Object obj, Int32 millisecondsTimeout, ref Boolean lockTaken); }

Now obviously, associating a sync block data structure with every object in the heap is quite wasteful, especially since most objects sync blocks are never used . To reduce memory usage, the CLR team uses a more efficient way to offer the functionality just described . Here s how it works: When the CLR initializes, it allocates an array of sync blocks . As discussed elsewhere in this book, whenever an object is created in the heap, it gets two additional overhead fields associated with it . The first overhead field, the type object pointer, contains the memory address of the type s type object . The second overhead field, the sync block index, contains an integer index into the array of sync blocks . When an object is constructed, the object s sync block index is initialized to -1, which indicates that it doesn t refer to any sync block . Then, when Monitor.Enter is called, the CLR finds a free sync block in the array and sets the object s sync block index to refer to the sync block that was found . In other words, sync blocks are associated with an object on the fly . When Exit is called, it checks to see if there are any more threads waiting to use the object s sync block . If there are no threads waiting for it, the sync block is free, Exit sets the object s sync block index back to -1, and the free sync block can be associated with another object in the future . Figure 29-1 shows the relationship between objects in the heap, their sync block indexes, and elements in the CLR s sync block array . Object-A, Object-B, and Object-C all have their type object pointer member set to refer to Type-T (a type object) . This means that all three objects are of the same type . As discussed in 4, Type Fundamentals, a type object is also an object in the heap, and like all other objects, a type object has the two overhead members: a sync block index and a type object pointer . This means that a sync block can be associated with a type object and a reference to a type object can be passed to Monitor s methods . By the way, the sync block array is able to create more sync blocks if necessary, so you shouldn t