(How)
C^# You Are - 1 April 2007

This week's questions are about threading.

1. How do you start a secondary thread?  Answer

   There are a variety of ways to start a secondary thread.  The most straightforward is to create an instance of the Thread class and then call the Start method.  Alternatively if you want to simply run a method in an arbitrary thread and you do not want much control over how it runs then ThreadPool.QueueUserWorkItem works.  If you want to do work on a secondary thread whil updating the main thread with progress information then look into BackgroundWorker.

2. How do you ensure that all secondary threads are terminated when the primary thread terminates?  Answer

   Ideally you should set up each of your threads to allow you to cancel them when you are about to close.  However if you set the IsBackground property of a Thread object to true then when the main thread terminates the secondary thread will as well.  There is, however, no guarantee about what state the secondary thread left the data in.

3. How can you synchronize two threads?  Answer

   You need to use a synchronization object.  There are a variety available: Mutex, ManualResetEvent, AutoResetEvent and Semaphore just to name a few.  In each case these objects allow you to set the object to some state in one thread and efficiently wait for the state change to occur in another thread.  In most cases you will use the WaitOne or WaitAny methods.  The base class for most synchronization objects is WaitHandle which exposes these methods.

   An alternative approach is to use Thread.Join.  This is useful when you want to block one thread while another completes.  Of course, in general, this is not that useful since you wouldn't be using threads if you wanted that to occur.  Nevertheless Join is useful for doing things like cleaning up secondary threads.

4. How can you pass state information to the worker thread?  Answer

   Since the worker thread requires a delegate you can store the state information in a class field and then use a method on the class as your worker thread method.  This is the general mechanism.  For example I might create a class called ProcessFile that handles file requests on secondary threads.  The filename would be something useful so I might store that information in a field of the ProcessFile class.

   In some cases it is not worth the effort to create a separate class.  In that case you can use a ParameterizedThreadStart delegate instead of the standard ThreadStart delegate.  The ParameterizedThreadStart delegates allows you to pass one object parameter to the thread.  You can therefore pass state information through the parameter rather than creating a whole new class.

5. Given that an application can have many threads running at once (both application and system created) how can you more easily identify your threads?  Answer

   Threads can have names.  A thread's name is shown in the VS debugger when looking at the running threads.  You can set the thread's name using the Name property.  This makes it easier to identify which threads are running what code.

6. What is a spinwait?  Answer

   An intriguing little tool used quite a bit in the operating system.  A spinwait is exactly what it says it is.  It is an object that will spin a given number of times.  It is basically a for-loop.  Spinwaits are useful when you want to wait for a given period of time but you do not want to give up the CPU.  Seldom useful outside low-level libraries they are nevertheless available.  .NET exposes the SpinWait class for this.  Note that the number of iterations is strictly dependent upon the speed of the processor so spinwaits are not useful for stalling a fixed amount of time without using additional components.

7. What does the lock statement do?  Answer

   The lock statement effectively enters a critical section represented by the object or type passed to it.  When an object is passed to the statement it effectively increments a lock count inside the object.  When the lock statement is executed and the lock count is greater than 0 then the thread will block until the lock count returns to zero.  When applied to a type the lock statement will block access for the type.  This is only useful when dealing with static methods.  In general you should use a private field as the lock target instead of the entire class or type.  This provides better performance because in most cases locks are not needed throughout an entire class. 

   All reference types in .NET have a lock field associated with them.  Normally it is null.  The first time you use a lock statement on an object it will allocate the lock field instance and use it instead.  The lock statement is equivalent to calling Monitor.Enter(lockField) when the block is entered and Monitor.Exit(lockField) when the block is left.  However it will also be called when an exception occurs so it is a lot cleaner.

   You should use the lock statement (or another synchronization object) for any method that can be accessed in multiple threads and will change data.  Other methods (such as those that read potentially modified data) should also be examined to see if they need locking.

8. What does the SynchronizeAttribute on a method do?  Answer

   Effectively this attribute, applied to a type member, puts a lock(this) around the member code.

9. What is an efficient, thread-safe way to increment numbers?  Answer

   Modern processors support atomic (in other words thread-safe) operations on numbers for certain operations.  These operations include increment, decrement, comparison, exchange and comparison and exchange.  .NET exposes these atomic operations using the Interlocked class.  For example if you used delay-initialization to avoid creating a field value until you needed it and the class had to be thread-safe then you could implement it like this.

   private SomeClass m_Data;
   public SomeClass Data
   {
      get
      {
         if (m_Data == null)
            m_Data = new SomeClass();
   
         return m_Data;
      }
   }
   

   The above code checks to see if the object had been created yet (not thread-safe).  If it has not then it is created and assigned to a private field (not thread-safe).  The field is then returned.  Assignment itself is atomic for reference types but nothing guarantees that between the check in the if statement and the assignment that someone else did not come along and initialize the data.  Here is a thread-safe version.

   private SomeClass m_Data;
   private object m_lckData = new object();
   public SomeClass Data
   {
      get
      {
         if (m_Data == null)
         {
            lock(m_lckData)
            {
               if (m_Data == null)
                  m_Data = new SomeClass();
            }
         };
   
         return m_Data;
      }
   }
   

   Not too bad but a little long and it requires that you define a synchronization object or use lock.  Notice that this method uses a technique known as double checking.  The first check is designed to catch the normal case of the object being created or not.  If it has not been created yet then we take the lock (which impacts performance) and then check again.  We have to check again because between the time our if statement ran and now someone else might have initialized the object.  So in the normal case we execute 1 if statement and take no locks.  In the initial case we will execute 2 if statements and a lock.  Here is an even better version.

   private SomeClass m_Data;
   public SomeClass Data
   {
      get
      {
         if (m_Data == null)
            Interlocked.CompareExchange(ref m_Data, new SomeClass(), null);
   
         return m_Data;
      }
   }

   This code is a lot cleaner and does not require any extra fields.  It has the same effect.  We first check to see if the object has been created yet.  If it hasn't then we will create a new instance.  However we then atomically check to see if the data is still null.  If it isn't then we assign the new instance to the field.  The only real difference between this code block and the last is that this code block might create a new instance of the field class before it realizes it is not needed. In general I find this to be a minor inconvenience.

10. What happens when an unhandled exception occurs on a secondary thread?  Answer

    This depends on what you called and what version of .NET you are running.  In most cases in v1.x an unhandled exception on a secondary thread was silently ignored.  In v2 unhandled exceptions in secondary threads will crash the application unless unhandled exceptions are being caught in the application.

    Some methods that run on secondary threads (for example Control.Invoke) will trap all exceptions and then re-raise them on the calling thread.  Refer to the documentation for any methods that you might use to determine whether they will do this or not.

    Finally note that there are a few exceptions that will never terminate the application even if they are unhandled.  Conseqeuently there are a couple of exceptions that will always terminate an application whether they are handled or not.