As mentioned, the order in which a thread runs is based strictly on its priority. If a thread is running and a thread with a higher priority becomes available to run, the running thread is preempted to allow the higher priority thread to run. If more than one thread has the same priority, the operating system executes them in a round-robin fashion.

In .NET, a thread's Priority property is used to get or set its priority level. It may have one of five values based on the ThreadPriority enum: Lowest, BelowNormal, Normal, AboveNormal, and Highest. The default is ThreadPriority.Normal.

You should override thread priorities only in situations where a task has a clearly defined need to execute with a low or high priority. Using thread priorities to fine-tune an algorithm can be self-defeating for several reasons:

.NET classifies each thread as either a background or foreground thread. The difference in these two types is quite simple: An application ends when all foreground threads stop; and any background threads still running are stopped as part of the shutdown process.

By default, a new thread is set to run as a foreground thread. It can be changed to background by setting its IsBackground property to true. Clearly, you only want to set this for noncritical tasks that can logically and safely end when the program does. Note that even though .NET attempts to notify all background threads when the program shuts down, it's good practice to explicitly manage thread termination.

During its lifetime, a thread may exist in several states: It begins life in an Unstarted state; after it is started and the CPU begins executing it, it is in Running mode; when its slice of execution time ends, the operating system may suspend it; or if it has completed running, it moves into Stopped mode. Running, Stopped, and Suspended are somewhat deterministic states that occur naturally as the operating system manages thread execution. Another state, known as WaitSleepJoin, occurs when a thread must wait for resources or for another thread to complete its execution. After this blocking ends, the thread is then eligible to move into Running mode.

Figure 13-2 illustrates the states that a thread may assume and the methods that invoke these states. It is not a complete state diagram, because it does not depict the events that can lead to a thread being placed in an inconsistent state. For example, you cannot start a running thread nor can you abort a suspended thread. Such attempts cause an interrupt to be thrown.

Figure 13-2. Thread states

A thread's current state is available through a read-only property named ThreadState. This property's value is based on the ThreadState enum that defines 10 states:

Aborted        = 256   StopRequested    = 1
AbortRequested = 128   Suspended        = 64
Background     = 4     SuspendRequested = 2
Running        = 0     Unstarted        = 8
Stopped        = 16    WaitSleepJoin    = 32

If a program is not interested in a specific state, but does need to know if a thread has been terminated, the Boolean Thread.IsAlive property should be used.

When a delegate is defined, .NET automatically creates a class to represent the delegate. Here is the code generated for the delegate in the preceding example:

// Class created from delegate declaration
public class myDelegate : MulticastDelegate
{
   // Constructor
   public myDelegate(Object target, Int32 methodPtr);
   public void virtual Invoke(string msg);
   // Used for asynchronous invocation
   public virtual IAsyncResult BeginInvoke(
           string msg, AsyncCallback callback,
           Object state);
   // Used to get results from called method
   public virtual void EndInvoke(IAsyncResult result);
   // Other members are not shown
}

A close look at the code reveals how delegates support both synchronous and asynchronous calls.

IAsyncResult IAsync =
      msgDelegate.BeginInvoke("Delegate Called.",null,null)

private delegate void myDelegate(string msg);
myDelegate d= new myDelegate(ShowMessage);
d.BeginInvoke("OK",new AsyncCallback(myCallBack),null);

// Save the interface returned
IAsyncResult IAsync = GetStatus.BeginInvoke(null,null);
// ... Do some work here; then get returned value
int status = GetStatus.EndInvoke(IAsync);

Table 13-1 lists the IAsyncResult properties that are instrumental in implementing the various asynchronous models. The class is in the System.Runtime.Remoting.Messaging namespace.

The WaitHandle and IsCompleted properties are often used together to implement polling logic that checks whether a method has finished running. Listing 13-1 illustrates this cooperation. A polling loop is set up that runs until IsCompleted is true. Inside the loop, some work is performed and the WaitHandle.WaitOne method is called to detect if the asynchronous method is done. WaitOne blocks processing until it receives a signal or its specified wait time (20 milliseconds in this example) expires.

// Code to return a Body Mass Index Value
private delegate decimal bmiDelegate(decimal ht, decimal wt);
decimal ht_in = 72;
decimal wt_lbs=168;
// (1) Invoke delegate asynchronously
bmiDelegate bd= new bmiDelegate(CalcBMI);
IAsyncResult asRes= bd.BeginInvoke(ht_in, wt_lbs,null,null);
int numPolls=0;
while(!asRes.IsCompleted)
{
   //     Do some work here
   // (2) Wait 20 milliseconds for method to signal completion
   asRes.AsyncWaitHandle.WaitOne(20,false);
   numPolls+=1;
}
// (3) Get result now that asynchronous method has finished
decimal myBMI = bd.EndInvoke(asRes);
Console.WriteLine("Polls: {0}  BMI: {1:##.00}",
      numPolls, myBMI);       // --> Polls: 3  BMI: 22.78
// Calculate BMI
private decimal CalcBMI(decimal ht, decimal wt)
{
   Thread.Sleep(200);         // Simulate a delay of 200 ms
   Console.WriteLine("Thread:{0}",
         Thread.CurrentThread.GetHash());
   return((wt * 703 *10/(ht*ht))/10);
}

For demonstration purposes, this example includes a 200-millisecond delay in the asynchronous method CalcBMI. This causes WaitOne, which blocks for up to 20 milliseconds, to execute seven times (occasionally eight) before the loop ends. Because EndInvoke is not reached until the asynchronous calculation has ended, it causes no blocking.

A more interesting use of the WaitHandle methods is to manage multiple asynchronous tasks running concurrently. In this example, the static WaitAll method is used to ensure that three asynchronous tasks have completed before the results are retrieved. The method is executed by passing it an array that contains the wait handle created by each call to BeginInvoke. As a side note, this point where threads must rendezvous before execution can proceed is referred to as a barrier.

int istart= Environment.TickCount;  // Start Time
bmiDelegate bd1     = new bmiDelegate(Form1.CalcBMI);
IAsyncResult asRes1 = bd1.BeginInvoke(72, 168,null,null);
//
bmiDelegate bd2     = new bmiDelegate(CalcBMI);
IAsyncResult asRes2 = bd2.BeginInvoke(62, 124,null,null);
//
bmiDelegate bd3     = new bmiDelegate(CalcBMI);
IAsyncResult asRes3 = bd3.BeginInvoke(67, 132,null,null);
// Set up array of wait handles as required by WaitAll method
WaitHandle[] bmiHandles = {asRes1.AsyncWaitHandle,
                           asRes2.AsyncWaitHandle,
                           asRes3.AsyncWaitHandle);
// Block execution until all threads finish at this barrier point
WaitHandle.WaitAll(bmiHandles);
int iend = Environment.TickCount;
// Print time required to execute all asynchronous tasks
Console.WriteLine("Elapsed Time: {0}", iend – istart);
// Get results
decimal myBMI1 = bd1.EndInvoke(asRes1);
decimal myBMI2 = bd2.EndInvoke(asRes2);
decimal myBMI3 = bd3.EndInvoke(asRes3);

To test performance, the method containing this code was executed multiple times during a single session. The results showed that execution time was more than 700 milliseconds for the first execution and declined to 203 for the fourth and subsequent ones when three different threads were allocated.

Execution:   1     2     3     4     5
Thread:     75    75    80    75    75
Thread:     75    80    12    80    80
Thread:     80    75    80    12    12
Time(ms):  750   578   406   203   203

For comparison, the code was then run to execute the three tasks with each BeginInvoke followed by an EndInvoke. It ran at a consistent 610 ms, which is what would be expected given the 200 ms block by each EndInvoke—and is equivalent to using synchronous code. The lesson to a developer is that asynchronous code should be used when a method will be executed frequently; otherwise the overhead to set up multithreading negates the benefits.

Core Note

Applications that need to host ActiveX controls or interact with the clipboard must apply the STAThread (single-threaded apartment) attribute to their Main() method. Unfortunately, you cannot use WaitAll() in applications that have this attribute due to conflicts between COM and the Win32 method that WaitAll wraps. Visual Studio users should be aware of this because C# under VS.NET adds the attribute by default.

Callbacks provide a way for a calling method to launch an asynchronous task and have it call a specified method when it is done. This is not only an intuitively appealing model, but is usually the most efficient asynchronous model—permitting the calling thread to focus on its own processing rather than waiting for an activity to end. As a rule, the callback approach is preferred when the program is event driven; polling and waiting are better suited for applications that operate in a more algorithmic, deterministic manner.

The next-to-last parameter passed to BeginInvoke is an optional delegate of type AsyncCallback. The method name passed to this delegate is the callback method that an asynchronous task calls when it finishes executing a method. The example in Listing 13-2 should clarify these details.

using System.Runtime.Remoting.Messaging ;
// Delegate is defined globally for class
public delegate decimal bmiDelegate(decimal wt, decimal ht);

public class BMIExample
{
   public void BMICaller(decimal ht, decimal wt, string name)
   {
      bmiDelegate bd= new bmiDelegate(CalcBMI);
      // Pass callback method and state value
      bd.BeginInvoke(ht,wt,new AsyncCallback(OnCallBack),name);
   }
   // This method is invoked when CalcBMI ends
   private void OnCallBack(IAsyncResult asResult)
   {
      // Need AsyncResult so we can get original delegate
      AsyncResult asyncObj = (AsyncResult)asResult;
      // Get state value
      string name= (string)asyncObj.AsyncState ;
      // Get original delegate so EndInvoke can be called
      bmiDelegate bd= (bmiDelegate)asyncObj.AsyncDelegate;
      // Always include exception handling
      try {
         decimal bmi = bd.EndInvoke(asResult);
         Console.WriteLine("BMI for {0}: {1:##.00}",name,bmi);
      } catch (Exception ex)
      {
         Console.WriteLine(ex.Message);
      }
   }
   private decimal CalcBMI(decimal ht, decimal wt)
   {
      Console.WriteLine("Thread:{0}",
            Thread.CurrentThread.GetHashCode());
      return((wt * 703 *10/(ht*ht))/10);
   }
}

Things to note:

When working with Windows Forms and user interfaces in general, it is important to understand that all controls on a form belong to the same thread and should be accessed only by code running on that thread. If multiple threads are running, a control should not be accessed—even though it's technically accessible—by any code not running on the same thread as the control. This is a .NET commandment; and as is the nature of commandments, it can be broken—but with unpredictable results. Suppose our application wants to use the callback method in the preceding example to display the calculated BMI value on a label control. One's instinct might be to assign the value directly to the control:

private void OnCallBack(IAsyncResult asResult)
{
   // ... Initialization code goes here
   decimal bmi = bd.EndInvoke(asResult);
   Label.Text= bmi.ToText();  // Set label on UI to BMI value
}

This may work temporarily, but should be avoided. As an alternative, .NET permits a limited number of methods on the Control class to be called from other threads: Invoke, BeginInvoke, EndInvoke, and CreateGraphics. Calling a control's Invoke or BeginInvoke method causes the method specified in the delegate parameter to be executed on the UI thread of that control. The method can then work directly with the control.

To illustrate, let's replace the assignment to Label.Text with a call to a method DisplayBMI that sets the label value:

DisplayBMI(bmi);

We also add a new delegate, which is passed to Invoke, that has a parameter to hold the calculated value.

// Delegate to pass BMI value to method
private delegate void labelDelegate(decimal bmi);

private void DisplayBMI(decimal bmi)
{
   // Determines if the current thread is the same thread
   // the Form was created on.
   if(this.InvokeRequired == false)
   {
      labelthread.Text= bmi.ToString("##.00");
   }
   else
   {
      // The Form's Invoke method is executed, which
      // causes DisplayBMI to run on the UI thread.
      // bmiObj is array of arguments to pass to method.
      object[] bmiObj= {bmi};
      this.Invoke(new labelDelegate(DisplayBMI),bmiObj);
   }
}

This code segment illustrates an important point about threads and code: The same code can be run on multiple threads. The first time this method is called, it runs on the same thread as OnCallBack. The InvokeRequired property is used to determine if the current thread can access the form. If not, the Invoke method is executed with a delegate that calls back DisplayBMI on the UI thread—permitting it to now interact with the UI controls. To make this an asynchronous call, you only need replace Invoke with BeginInvoke.

In situations where your code needs to create a new thread but does not require passing arguments or receiving a return value, the system-defined MethodInvoker delegate should be considered. It is the simplest possible delegate—it takes no parameters and returns no value. It is created by passing the name of a method to be called to its constructor. It may then be invoked synchronously (Invoke) or asynchronously (BeginInvoke):

// NewThread is method called by delegate
MethodInvoker mi = new MethodInvoker(NewThread);
// Note that parameters do not have to be null
mi.BeginInvoke(null,null); // Asynchronous call
mi();                      // Synchronous call

The advantage of using the built-in delegate is that you do not have to design your own, and it runs more efficiently than an equivalent custom delegate.

Asynchronous operations are not new; they were originally implemented in operating systems via hardware and software as a way to balance the slow I/O (Input/Output) process against the much faster CPU operations. To encourage asynchronous I/O, the .NET Framework includes methods on its major I/O classes that can be used to implement the asynchronous model without explicitly creating delegates or threads. These classes include FileStream, HttpWebRequest, Socket, and NetworkStream. Let's look at an example using the FileStream class that was introduced in Chapter 5, “C# Text Manipulation and File I/O.”

FileStream inherits from the System.IO.Stream class an abstract class that supports asynchronous operations with its BeginRead, BeginWrite, EndRead, and EndWrite methods. The Beginxxx methods are analogous to BeginInvoke and include callback and status parameters; the Endxxx methods provide blocking until a corresponding Beginxxx method finishes.

The code in Listing 13-3 uses BeginRead to create a thread that reads a file and passes control to a callback method that compresses the file content and writes it as a .gz file. The basic callback method operations are similar to those in Listing 13-2. Note how the file name is retrieved from the AsyncState property. The compression technique—based on the GZipStream class—is available only in .NET 2.0 and above.

// Special namespaces required:
using System.IO.Compression;
using System.Runtime.Remoting.Messaging;
//
// Variables with class scope
Byte[] buffer;
FileStream infile;
// Compress a specified file using GZip compression
private void Compress_File(string fileName)
{
   bool useAsync = true;  // Specifies asynchronous I/O
   infile = new FileStream(fileName, FileMode.Open,
         FileAccess.Read, FileShare.Read, 2000, useAsync);
   buffer = new byte[infile.Length];
   int ln = buffer.Length;
   // Read file and let callback method handle compression
   IAsyncResult ar = infile.BeginRead(buffer, 0, ln,
         new AsyncCallback(Zip_Completed), fileName);
   //
}
// Callback method that compresses raw data and stores in file
private void Zip_Completed(IAsyncResult asResult)
{
   // Retrieve file name from state object
   string filename = (string)asResult.AsyncState;
   infile.EndRead(asResult);   // Wrap up asynchronous read
   infile.Close();
   //
   MemoryStream ms = new MemoryStream();
   // Memory stream will hold compressed data
   GZipStream zipStream = new GZipStream(ms,
         CompressionMode.Compress, true);
   // Write raw data in compressed form to memory stream
   zipStream.Write(buffer, 0, buffer.Length);
   zipStream.Close();
   // Store compressed data in a file
   FileStream fs = new FileStream(filename+".gz",
         FileMode.OpenOrCreate,FileAccess.Write,FileShare.Read);
   byte[] compressedData = ms.ToArray();
   fs.Write(compressedData, 0, compressedData.Length);
   fs.Close();
}

As a rule, asynchronous techniques are not required for file I/O. In fact, for read and write operations of less than 64KB, .NET uses synchronous I/O even if asynchronous is specified. Also, note that if you specify asynchronous operation in the FileStream constructor (by setting the useAsync parameter to true), and then use synchronous methods, performance may slow dramatically. As we demonstrate in later chapters, asynchronous techniques provide a greater performance boost to networking and Web Services applications than to file I/O.

All code runs on either the primary thread or a worker thread that is accessible through the CurrentThread property of the Thread class. We can use this thread to illustrate some of the selected Thread properties and methods that provide information about a thread:

Thread currThread = Thread.CurrentThread;
Console.WriteLine(currThread.GetHashCode());
Console.WriteLine(currThread.CurrentCulture);      // en-US
Console.WriteLine(currThread.Priority);            // normal
Console.WriteLine(currThread.IsBackground);        // false
Console.WriteLine(AppDomain.GetCurrentThreadId()); // 3008

Thread.GetHashCode overrides the Object.GetHashCode method to return a thread ID. The thread ID is not the same as the physical thread ID assigned by the operating system. That ID, which .NET uses internally to recognize threads, is obtained by calling the AppDomain.GetCurrentThreadID method.

To create a thread, pass its constructor a delegate that references the method to be called when the thread is started. The delegate parameter may be an instance of the ThreadStart or ParameterizedTheadStart delegate. The difference in the two is their signature: ThreadStart accepts no parameters and returns no value; ParameterizedThreadStart accepts an object as a parameter, which provides a convenient way to pass data to thread.

After the thread is created, its Start method is invoked to launch the thread. This segment illustrates how the two delegates are used to create a thread:

Thread newThread  = new Thread(new ThreadStart(GetBMI));
newThread.Start();      // Launch thread asynchronously

Thread newThread  = new Thread(new
      ParameterizedThreadStart(GetBMI));
newThread.Start(40);    // Pass data to the thread

To demonstrate thread usage, let's modify the method to calculate a BMI value (see Listing 13-2) to execute on a worker thread (Listing 13-4). The weight and height values are passed in an array object and extracted using casting. The calculated value is exposed as a property of the BMI class.

// Create instance of class and set properties
BMI b = new BMI();
decimal[] bmiParms = { 168M, 73M };  // Weight and height
// Thread will execute method in class instance
Thread newThread  = new Thread(
      new ParameterizedThreadStart(b.GetBMI));
newThread.Start(bmiParms);        // Pass parameter to thread
Console.WriteLine(newThread.ThreadState);  // Unstarted
Console.WriteLine(b.Bmi); // Use property to display result
// Rest of main class ...
}
public class BMI
{
   private decimal bmival;
   public void GetBMI(object obj)
   {
      decimal[] parms= (decimal[])obj;
      decimal weight = parms[0];
      decimal height = parms[1] ;


      // Simulate delay to do some work
      Thread.Sleep(1000);  // Build in a delay of one second
      bmival = (weight * 703 * 10/(height*height))/10 ;
   }
   // Property to return BMI value
   public decimal Bmi
   { get {return bmival; }}
}

In reality, the method GetBMI does not do enough work to justify running on a separate thread; to simulate work, the Sleep method is called to block the thread for a second before it performs the calculation. At the same time, the main thread continues executing. It displays the worker thread state and then displays the calculated value. However, this logic creates a race condition in which the calling thread needs the worker thread to complete the calculation before the result is displayed. Because of the delay we've included in GetBMI, that is unlikely—and at best unpredictable.

One solution is to use the Thread.Join method, which allows one thread to wait for another to finish. In the code shown here, the Join method blocks processing on the main thread until the thread running the GetBMI code ends execution:

newThread.Start();
Console.WriteLine(newThread.ThreadState);
newThread.Join();        // Block until thread finishes
Console.WriteLine(b.bmi);

Note that the most common use of Join is as a safeguard to ensure that worker threads have terminated before an application is shut down.

Any started thread that is not in a suspended state can be requested to terminate using the Thread.Abort method. Invoking this method causes a ThreadAbortException to be raised on its associated thread; thus, the code running the thread must implement the proper exception handling code. Listing 13-5 shows the code to implement both the call and the exception handling.

The calling method creates a thread, sleeps for a second, and then issues an Abort on the worker thread. The parameter to this command is a string that can be displayed when the subsequent exception occurs. The Join command is then used to wait for the return after the thread has terminated.

The method running on the worker thread loops until it is aborted. It is structured to catch the ThreadAbortException raised by the Abort command and print the message exposed by the exception's ExceptionState property.

using System;
using System.Threading;
class TestAbort
{
   public static void Main()
   {
      Thread newThread = new Thread(new ThreadStart(TestMethod));
      newThread.Start();
      Thread.Sleep(1000);
      if(newThread.IsAlive)
      {
         Console.WriteLine("Aborting thread.");
         // (1) Call abort and send message to Exception handler
         newThread.Abort("Need to close all threads.");
         // (2) Wait for the thread to terminate
         newThread.Join();
         Console.WriteLine("Shutting down.");
      }
   }

   static void TestMethod()
   {
      try
      {
         bool iloop=true;
         while(iloop)
         {
            Console.WriteLine("Worker thread running.");
            Thread.Sleep(500);
            // Include next statement to prevent abort
            // iloop=false;
         }
      }
      catch(ThreadAbortException abortException)
      {
        // (3) Display message sent with abort command
        Console.WriteLine((string)abortException.ExceptionState);
      }
   }
}

The Abort command should not be regarded as a standard way to terminate threads, any more than emergency brakes should be regarded as a normal way to stop a car. If the thread does not have adequate exception handling, it will fail to perform any necessary cleanup actions—leading to unpredictable results. Alternate approaches to terminating a thread are presented in the section on thread synchronization.

To use the Timer class, simply register an event handling method or methods with the class's Elapsed event. The signature of the method(s) must match that of the ElapsedEventHandler delegate associated with the event:

public delegate void ElapsedEventHandler(object sender,
                                         ElapsedEventArgs e);

The Elapsed event occurs at an interval specified by the Timer.Interval property. A thread from the thread pool is used to make the call into the event handler(s). This code segment demonstrates how the Timer causes a method to be called every second:

using System;
using System.Timers;


public class TimerTest
{
   public static void Main()
   {
      SetTimer t = new SetTimer();
      t.StartTimer();
   }
}
class SetTimer
{
   int istart;
   public void StartTimer()
   {
      istart= Environment.TickCount; //Time when execution begins
         Timer myTimer = new myTimer();
         myTimer.Elapsed+=new ElapsedEventHandler(OnTimedEvent);
      myTimer.Interval=1000;           // 1000 milliseconds
      myTimer.Enabled=true;
      Console.WriteLine("Press any key to end program.");
      Console.Read();
      myTimer.Stop();
   }
   // Timer event handler
   private void OnTimedEvent(object source, ElapsedEventArgs e)
   {
      Console.WriteLine("Elapsed Time: {0}",
                        Environment.TickCount-istart);
   }
}

We can dispense with a code example of this class, because its implementation parallels that of the Timers.Timer class, with two differences: It uses a Tick exception rather than Elapsed, and it uses the familiar EventHandler as its delegate. However, the feature that distinguishes it from the other Timer class is that it does not use a thread from the thread pool to call a method. Instead, it places calls on a queue to be handled by the main UI thread. Except for situations where the time required by the invoked method may make the form unresponsive, a timer is preferable to using threading. It eliminates the need to deal with concurrent threads and also enables the event handler to directly update the form's controls—something that cannot be done by code on another thread.

Monitor.Enter takes an object as a parameter and attempts to grant the current thread exclusive access to the object. If another thread owns the object, the requesting thread is blocked until the object is free. The object is freed by executing the complementary Monitor.Exit.

To illustrate the use of a monitor, let's return to the example in Listing 13-8 in which two threads compete to read and update a log file. The read and write operations are performed by calling the UpdateLog method on a WorkClass object. To ensure these operations are not interrupted, we can use a monitor to lock the object until the method completes executing. As shown here, it requires adding only two statements:

public void CallUpdate()
{
   Monitor.Enter(wc);   // wc is WorkClass object
   wc.UpdateLog();
   Monitor.Exit(wc);

In addition to Monitor.Enter, there is a Monitor.TryEnter method that attempts to acquire an exclusive lock and return a true or false value indicating whether it succeeds. Its overloads include one that accepts a parameter specifying the number of millseconds to wait for the lock:

if (!Monitor.TryEnter(obj) return; // Return if lock unavailable
if (!Monitor.TryEnter(obj, 500) return; // Wait 500 ms for lock

A problem with the preceding approach is that it relies on clients to use the monitor for locking; however, there is nothing to prevent them from executing UpdateLog without first applying the lock. To avoid this, a better design approach is to encapsulate the lock(s) in the code that accesses the shared resource(s). As shown here, by placing Monitor.Enter inside UpdateLog, the thread that gains access to this lock has exclusive control of the code within the scope of the monitor (to the point where Monitor.Exit is executed).

public void UpdateLog()
{
   Monitor.Enter(this);   // Acquire a lock
   try
   {
      // Code to be synchronized
   }
   finally   // Always executed
   {
      Monitor.Exit(this);   // Relinquish lock
   }

Note the use of finally to ensure that Monitor.Exit executes. This is critical, because if it does not execute, other threads calling this code are indefinitely blocked. To make it easier to construct the monitor code, C# includes the lock statement as a shortcut to the try/finally block. For example, the previous statements can be replaced with the following:

lock(this)
{
   // Code to be synchronized
}

Monitor and lock can also be used with static methods and properties. To do so, pass the type of object as a command parameter rather than the object itself:

Monitor.Enter(typeof(WorkClass));
// Synchronized code ...
Monitor.Exit(typeof(WorkClass));

Core Recommendation

Be wary of using synchronization in static methods. Deadlocks can result when a static method in class A calls static methods in class B, and vice versa. Even if a deadlock does not occur, performance is likely to suffer.