• If you haven’t read ReaderWriterLock, i would suggest read that first at http://www.sanjaysingh.net/2010/11/thread-synchronization-techniques_9866.html
• This class was introduced in .NET framework 3.5. This is similar to ReaderWriterLock but it has simplified rules for recursive locks and for upgrading and downgrading lock state and this avoids many cases of potential deadlocks.
• Microsoft recommends it for all future development.
• By default, new instances of ReaderWriterLockSlim are created with LockRecursionPolicy.NoRecusrion and therefore do not allow recursive lock calls. Contrast this with ReaderWriterLock which defaults to allowing recursive locks making your code more prone to deadlocks. For example, if the current thread entered read mode and it makes another call to acquire read lock, LockRecursionException is thrown. But remember that ReaderWriterLockSlim can also be instantiated to allow for recursive locks, and in that case this call will be allowed.
• A thread can enter lock in three modes -  read mode, write mode and upgradable read mode.
• Regardless of the recursion policy, only one thread can be in write mode at any given time. When one thread is in write mode, no other thread can enter the lock in any mode.
• Only one thread can be in upgradable mode at any given time.
• Any number of threads can be in read mode.

Below, i will give the same BookStore example explained in the above link using ReaderWriterLockSlim class. Behavior of the class remains same. Note the difference of use.

public class Book
{
    public string Title { get; private set; }
    public string Publisher { get; private set; }
    public string Author { get; private set; }
    public uint PublishYear { get; private set; }

    public Book(string title, string publisher, string author, uint publishYear)
    {
        this.Title = title;
        this.Publisher = publisher;
        this.Author = author;
        this.PublishYear = publishYear;
    }
}

public class BookStore
{
    private List Books = new List();
    private ReaderWriterLockSlim BooksLock = new ReaderWriterLockSlim();

    public BookStore()
    {
        // Populate Books
    }

    public void AddBook(Book newBook)
    {
        if (this.BooksLock.TryEnterWriteLock(2000))
        {
            try
            {
                this.Books.Add(newBook);
                Console.WriteLine("Book Added");
            }
            finally
            {
                this.BooksLock.ExitWriteLock();
            }
        }
    }

    public Book GetBook(string title, string author)
    {
        Book requiredBook = null;

        if (this.BooksLock.TryEnterReadLock(2000))
        {
            try
            {
                foreach (Book currBook in this.Books)
                {
                    if (currBook.Title.Equals(title) && currBook.Author.Equals(author))
                    {
                        requiredBook = currBook;
                        break;
                    }
                }
            }
            finally
            {
                this.BooksLock.ExitReadLock();
            }
        }
        return requiredBook;
    }

    public int GetBooksCount()
    {
        int count = 0;

        if (this.BooksLock.TryEnterReadLock(2000))
        {
            try
            {
                count = this.Books.Count;
            }
            finally
            {
                this.BooksLock.ExitReadLock();
            }
        }
        return count;
    }
}

• ReaderWriterLock class defines a lock that supports single writer and multiple readers. This is used to synchronize access to a resource. In situations where resource is changed infrequently, a ReaderWriterLock provides better throughput than normal locks like Monitor. A thread can hold a reader lock or a writer lock but not both. Every call to acquire a lock increases the lock count. So you have to call release lock as many times as you call acquire lock. Readers and Writers are queued separately. When a thread releases a writer lock, all threads waiting in the reader queue are granted reader locks. When all of those reader locks have been released, the next thread waiting in the writer queue, if any, is granted the writer lock, and so on. When a thread in the writer queue is waiting for active readers locks to be released, threads requesting new reader locks accumulate in the reader queue. This helps protect writers against indefinite blockage by readers. Most methods for acquiring locks on ReaderWriterLock accept time-out values. Use time-out to avoid deadlocks in your application.

Below, i will show the use of ReaderWriterLock class. We have a BookStore class and a Book class. BookStore class maintains a collection of Books. ReaderWriterLock makes perfect sense here because in BookStore write operation is less frequent than read operation (You get new books less frequently than number of customers that you have to cater to).

public class Book
{
    public string Title { get; private set; }
    public string Publisher { get; private set; }
    public string Author { get; private set; }
    public uint PublishYear { get; private set; }

    public Book(string title, string publisher, string author, uint publishYear)
    {
        this.Title = title;
        this.Publisher = publisher;
        this.Author = author;
        this.PublishYear = publishYear;
    }
}

public class BookStore
{
    private List Books = new List();
    private ReaderWriterLock BooksLock = new ReaderWriterLock();

    public BookStore()
    {
        // Populate Books
    }

    public void AddBook(Book newBook)
    {
        this.BooksLock.AcquireWriterLock(2000);
        try
        {
            this.Books.Add(newBook);
        }
        finally
        {
            this.BooksLock.ReleaseWriterLock();
        }
    }

    public Book GetBook(string title, string author)
    {
        Book requiredBook = null;
        this.BooksLock.AcquireReaderLock(2000);
        try
        {
            foreach (Book currBook in this.Books)
            {
                if (currBook.Title.Equals(title) && currBook.Author.Equals(author))
                {
                    requiredBook = currBook;
                    break;
                }
            }
        }
        finally
        {
            this.BooksLock.ReleaseReaderLock();
        }
        return requiredBook;
    }

    public int GetBooksCount()
    {
        int count = 0;
        this.BooksLock.AcquireReaderLock(2000);
        try
        {
            count = this.Books.Count;
        }
        finally
        {
            this.BooksLock.ReleaseReaderLock();
        }
        return count;
    }
}

AddBook method acquires writer lock and GetBook and GetBookCount method acquires reader lock. Note that we release lock in the finally block to ensure that lock is released whatever the case be.

• Windows follows what is called preemtive multithreading where a thread can be suspended after loading a value from memory address, but before having a chance to alter it and store it. Thus calls like following is not guaranteed to be atomic:

x += 1;

• Interlocked class provides methods that synchronize access to a variable that is shared by multiple threads. Interlocked operations are atomic meaning the entire operation is a unit that cannot be interrupted by another interlocked operation on the same variable.

Following is example of some of the commonly used Interlocked methods -

// 5 is added to variable variableToBeAdded and value is stored in it, as an atomic operation.
Interlocked.Add(ref variableToBeAdded, 5);

// Increments a specified variable variableToBeIncremented by 1 and stores the result in it, as an atomic operation.
Interlocked.Increment(ref variableToBeIncremented);

// Decrements a specified variable valueToBeDecremented by 1 and stores the result in it, as an atomic operation.
Interlocked.Decrement(ref valueToBeDecremented);

// Assigned 10 to variableToBeAssigned as an atomic operation.
Interlocked.Exchange(ref variableToBeAssigned, 10);

// Checks to see if variableToBeCompared is 2 and if it is then assigns 3 to it.
Interlocked.CompareExchange(ref variableToBeCompared, 3, 2);

Also note that all of these methods have overloads for different types of variables like int, long, float, double etc.

• Mutex is a synchronization technique that grants exclusive access to the shared resource to only one thread. If a thread acquires a mutex, second thread that wants to acquire that mutex is suspended until the first thread releases the mutex.
• The thread that own a mutex can request the same mutex without blocking its execution.
• You can use **WaitOne **method to request ownership of a mutex. **ReleaseMutex **should be called to release ownership of a mutex. If you acquire same mutex multiple times, you will have to call **ReleaseMutex **as many times to release the mutex.
• If a thread terminates while owning a mutex, the state of the mutex is set to signaled and the next waiting thread gets ownership.
• A mutex are of two types – local mutex, which are unnamed and named mutex. A local mutex exists only within your process. It can be used by any thread in your process that has reference to the Mutex object that represents the mutex. Named mutex objects are visible throughout the operating system and can be used to synchronize the activities of processes.

Following example uses mutex to make an application single-instance. As said above, named mutex can be used for cross process synchronization, we take advantage of this to achieve single instance behavior for our application. Here is the sample application.

using System;
using System.Threading;
using System.Reflection;

namespace ConsoleApplication1
{
    class Program
    {
        const string ApplicationID = "B45CFE7E-8E19-4a83-8782-859E006AD576";
        static void Main(string[] args)
        {
            string applicationName = Assembly.GetEntryAssembly().GetName().Name;
            Mutex startupMutex = new Mutex(false, ApplicationID);
            if (startupMutex.WaitOne(1))
            {
                Console.WriteLine(string.Format("{0} is running.",applicationName));

                // do your stuff
                Console.ReadLine();
            }
            else
            {
                Console.WriteLine(string.Format("{0} is already running.Exiting..",applicationName));
                Console.ReadLine();
            }
            
        }
    }
}

AutoResetEvent and ManualResetEvent are what is called Wait Handles that is used to signal the state of one thread to another thread. Threads can use wait handles to notify other threads that they need exclusive access to a resource. Other threads must then wait to use this resource until the Wait Handle is no longer in use. Wait Handles have two states signaled and nonsignaled. A Wait Handle that is not owned by any thread is in the signaled state. A Wait Handle that is owned by a thread is in the nonsignaled state.

• Threads request ownership of a wait handle by calling one of the wait methods, such as WaitOne, WaitAny, or WaitAll. All of these methods are blocking calls. If no other thread owns the wait handle, the call immediately returns true, the wait handle’s status is changed to nonsignaled, and the thread that owns the wait handle continues to run.
• Threads that own a wait handle call the Set method when they are done.
• Other threads can reset the status of a wait handle to nonsignaled by calling the reset method.
• Once it has been signaled ManualResetEvent remains signaled until it is manually reset. That is calls to WaitOne return immediately.
• AutoResetEvent resets automatically after each release. For example, let’s assume that we have three threads waiting on a manual reset event wait handle. As soon as we signal (Set) this ManualResetEvent, all the three threads are released. In contrast, had it been AutoResetEvent, it would release only one thread, resetting the state automatically.

Following sample class simulates processing of network data. Methods ReceiveData and ProcessData run on two different threads. Note that here we are achieving synchronization between the thread using AutoResetEvent. The ReceiveData thread is continuously generating data and pushing it into buffer. It also signals the AutoResetEvent as soon as some data is received. The ProcessData thread waits on the AutoResetEvent and processes the data as soon as signaled.

Note that we do not need to reset the AutoResetEvent, as it is automatically done after every set. Look at the example now:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;

namespace ConsoleApplication1
{
    public class NetworkDataSimulator
    {
        private AutoResetEvent autoResetEvent = new AutoResetEvent(false);
        private List buffer = new List();
        private Random rand = new Random(100);

        public void ReceiveData()
        {
            while (true)
            {
                // Simulate arrival of some data
                string data = rand.Next().ToString();

                // let us put the data in buffer
                lock (buffer)
                {
                    buffer.Add(data);
                    Console.WriteLine(string.Format("Data Received - {0}", data));
                    autoResetEvent.Set();
                }

                // simualte some delay
                Thread.Sleep(2000);
            }
        }

        public void ProcessData()
        {
            while (true)
            {
                autoResetEvent.WaitOne();
                lock (buffer)
                {
                    // Process received data
                    foreach (string dataElement in buffer)
                    {
                        Console.WriteLine(string.Format("Data Processed - {0}",dataElement));
                    }
                    buffer.Clear();
                }
                Thread.Sleep(2000);
            }
        }
    }
}

Call these two threads as follows and check the behavior of how they synchronize.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            NetworkDataSimulator nds = new NetworkDataSimulator();
            (new Thread(nds.ProcessData)).Start();
            (new Thread(nds.ReceiveData)).Start();
            
        }
    }
}

Monitor is the most fundamental thread synchronization technique in the .NET Framework. This can be used to synchronize access to what is called critical section by multiple threads. I am going to present an example first and then we will discuss that:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;

namespace WpfApplication1
{
    public class Person
    {
        public string Name
        {
            get;
            private set;
        }

        public string Age
        {
            get;
            private set;
        }

        public void SetData(string name, string age)
        {
            try
            {
                Monitor.Enter(this);
                this.Name = name;
                this.Age = age;
            }
            finally
            {
                Monitor.Exit(this);
            }
        }
    }
}

Look at the SetData method. Here, setting name and age of the person is an atomic operation for us. This is also a critical section for us that we want to make thread safe. Note that if we do not synchronize this section in a multithreaded application, then we may end up having corrupt name and age values for a person object. Monitor.Enter method acquires an exclusive lock on “this” object if it is not already acquired. If the second thread tries to enter this method while first thread is still executing it, it will block at Monitor.Enter call. Note that the lock is identified by the Object that is passed to the enter method, so take extreme care in deciding what object to use to acquire lock -  particularly when your contains multiple critical sections. Otherwise, you may end up in deadlock. Each call to Monitor.Enter should be complemented with a call to Monitor.Exit to release the lock. The idea is that only one thread can be inside the Monitor at any one time. C# .NET also provides a language specific construct “lock” to be used in this scenario. Following is the implementation of the above method “SetData” using “lock” construct:

public void SetData(string name, string age)
{
    lock (this)
    {
        this.Name = name;
        this.Age = age;
    }
}

This implementation of “SetData” is exactly same as the implemented using Monitor. “lock” is C# language construct which get translated to Monitor calls in the compiled code.

In a multithreaded applications, you often need to synchronize individual threads with other parts of your program. Synchronization techniques are used to control following two things:

• To control the order in which code runs whenever task must be performed in a specific sequence.
• To prevent the problems that can occur when two threads share the same resources at the same time.

For example, in a networking application, one thread might continuously listen on the socket for incoming packets and adds whatever it receives to the Queue. Second thread on the other hand is waiting on the Queue and it process the message as soon as it gets something. We need synchronization here because both threads are using the same shared resource “the Queue”.

There are several thread synchronization techniques to address these issues. I will discussing those techniques one by one in later articles.

• Dispatcher is an instance of the class System.Windows.Threading.Dispatcher. Dispatcher maintains a prioritized queue of work items for a specific thread. When the Dispatcher is created on a thread, it becomes the only Dispatcher that can be associated with the thread, even if the Dispatcher is shut down. If you attempt to get the CurrentDispatcher for the current thread and a Dispatcher is not associated, a Dispatcher will be created. If a Dispatcher is shut down, it cannot be restarted. In WPF, a DispatcherObject can only be accessed by the Dispatcher it is associated with. Note that every visual (Textbox, Combobox etc) inherits from DispatcherObject. For this reason, a background thread cannot update the content of a Button that is associated with the Dispatcher on the UI thread. This is accomplished using either Invoke or BeginInvoke. Invoke is synchronous and BeginInvoke is asynchronous. The operation is added to the queue of the Dispatcher at the specified DispatcherPriority.

Following code generates exception “The calling thread cannot access this object because a different thread owns it”.

public partial class Window1 : Window { public Window1() { InitializeComponent(); Thread mythread = new Thread(() => this.MyButton.Content = “New Value”); mythread.Start(); } }

Here MyButton is a Button added to window1 and we are trying to set its content from a different thread. As mentioned above, this is illegal. Following is the correct way of doing this. Note the use of Dispatcher.

public partial class Window1 : Window
{
    public Window1()
    {

        InitializeComponent();
        Thread mythread = new Thread(() => this.MyButton.Dispatcher.Invoke((Action)(() => this.MyButton.Content = "New Value"),DispatcherPriority.Normal));
        mythread.Start();
    }
}

Here I will show you how to write an UPDATE statement in SQL Server to update different rows on different conditions.

Following UPDATE sql statement updates salaries of the Employee table, giving 20% raise to the employees having salary less than or equal to 5000, 10% raise to the employees having salary between 5000 and 10000, 5% raise to the employees having salary between 10000 and 20000, and no raise for the employees with salary greater then or equal to 30000.

UPDATE EMPLOYEE
SET Salary = CASE
                WHEN Salary <= 5000 THEN Salary* 1.20
                WHEN Salary <= 10000 THEN Salary * 1.10
                WHEN Salary <= 20000 THEN Salary * 1.05
                ELSE Salary
            END

SQL Server gives a very useful tool ‘Database Publish Wizard’ that can be used to script and publish SQL Server database. For SQL Server 2005 installation, this tool is usually located at **[Program Files]\Microsoft SQL Server\90\Tools\Publishing\SqlPubWiz.exe. **This tool has both command line as well as GUI interface.

Here I am going to show some sample command line queries that can be used to generate database scripts. For the sake of example, let us assume that database name is “MyDatabase” which is hosted on SQL Server instance “SQLEXPRESS” on the local machine.

Following command will give you script for schema (not data) of the database. The script is output to a text file C:\Script.txt.

SqlPubWiz.exe script -S .\SQLEXPRESS -d MyDatabase -schemaonly -f C:\Script.txt

Option “-S” specifies the SQL Server instance. Options “-d” specifies the database to script. Options “-schemaonly” specifies that we want to script only schema. Options “-f” specifies the output file.

SqlPubWiz by default works in windows authentication mode. So if your Server does not allow for windows authentication, you will also need to specify user name and password with “-U” and “-P” option respectively.

In the same way as above command, following command will generate script for all the data of the database. It will not contain any schema script.

SqlPubWiz.exe script -S .\SQLEXPRESS -d MyDatabase -dataonly -f C:\Script.txt

We can even use Management Studio to generate database scripts (Right click database, select Task and then select Generate Scripts). However, there is no options in management studio to generate “dataonly” scripts in which case this tool comes handy.