In Java, the keyword synchronized is used to ensure that only one thread will enter a specific section of code at a time. In the following example, Java ensures that a thread will not enter the code block containing the comment until an exclusive lock has been obtained on the this object.

public void doSomething() {
    synchronized (this) {
        // some synchronized operation
    }
}

When the thread exits the code section, Java will automatically release the lock so that another thread can attempt to acquire it and enter the synchronized code block.

C# provides the keyword lock, which does the same thing. The Java fragment above is translated to C# as follows:

public void doSomething() {
    lock (this) {
        // some synchronized operation
    }
}

C# doesn’t provide a direct analog of using the Java synchronized keyword as a method modifier, but the same effect can be achieved by annotating the method with the MethodImpl(MethodImplOptions.Synchronized) attribute.

So a synchronized method in Java:

private synchronized void doLock() {
    // do something
}

looks like this in C#:

[MethodImpl(MethodImplOptions.Synchronized)]
private void doLock() {
    // do something
}

The MethodImpl attribute is defined in the System.Runtime.CompilerServices namespace, so this must be imported before the method can be annotated. Key points worth highlighting include the following:

In Java, the Object class contains the methods wait, notify, and notifyAll. The .NET Object class doesn’t contain the equivalent methods, but the System.Threading.Monitor class exposes the required functionality, as detailed in Table 13-4.

The only significant difference is that the Monitor class requires the programmer to pass in an object on which to acquire a lock. Like Java, C# requires these calls to be performed within a synchronized section of code, which is accomplished using the lock keyword.

The Monitor class also provides some functionality that Java doesn’t have, giving the programmer more control over how locks are acquired and released.

Although most of the synchronization support in .NET works based on acquiring a lock on a target Object, a different model is available in the ReaderWriterLock class. This class maintains two levels of lock, an exclusive lock for writers and a nonexclusive one for readers. Many readers are allowed to acquire the read lock simultaneously, but only if the write lock isn’t held. One writer can acquire the write lock, but only if there are no active readers. Readers can upgrade to get a handle on the write lock.

We won’t cover this class in detail because its use is simple and obvious. This class is ideal for implementing custom collections.

The Java language specification guarantees that any operation on a 32-bit or smaller value will be atomic, without the need to explicitly synchronize access to the variable. With its richer set of data types, .NET takes a different approach, allowing the developer to use the Interlocked class to implement atomic access to variables. Interlocked allows int and long types to be exchanged, incremented, and decremented in a thread-safe manner, with the same effect as wrapping the operations in a lock block. For example:

private void incrementCounter() {
    lock (this) {
        o_counter++;
    }
}

This fragment can be rewritten to use Interlocked as follows:

private void incrementCounter() {
    Interlocked.Increment(ref o_counter);
}

Using the Interlocked class introduces tidier code and removes the need to use typeof to protect static variables. The variable must be annotated with the ref keyword to ensure that the target variable is modified. Omitting the annotation causes the value of the instance to be copied and modified without affecting the original instance, in which case simultaneous calls to Interlocked will be dealing with different values.

The WaitHandle class is used as a base class for synchronization classes that interoperate with the native operating system. The class defines a signaling mechanism that is used to indicate that a shared resource has been acquired or released. The significance of this class comes from the static methods that allow callers to block until one or more instances of WaitHandle are signaled. Three methods are available:

The three classes in the namespace that are derived from WaitHandle are discussed in the following sections.

Mutex x_mutex = new Mutex(false, "shared");
Console.WriteLine("Created mutex");

while (true) {
    string x_str = Console.ReadLine();
    if (x_str.Equals("a")) {
        Console.WriteLine("Attempting to acquire...");
        x_mutex.WaitOne();
        Console.WriteLine("Acquired the mutex");
    } else if (x_str.Equals("r")) {
        Console.WriteLine("Releasing");
        x_mutex.ReleaseMutex();
        Console.WriteLine("Released");
    }
}

class AutoEvent {
    AutoResetEvent o_event = new AutoResetEvent(false);

    public AutoEvent() {
        Thread x_thread = new Thread(new ThreadStart(run));
        x_thread.Start();

        while (true) {
            if (Console.Read() == 's') {
                o_event.Set();
            }
        }
    }

    public void run() {
        while (true) {
            o_event.WaitOne();
            Console.WriteLine("Event signalled");
        }
    }
}