Provides a mechanism that synchronizes access to objects. [Edit]

See Also: Monitor Members

[System.Runtime.InteropServices.ComVisible(true)] public static class Monitor

Thread Safety

All public static members of this type are safe for multithreaded operations. No instance members are guaranteed to be thread safe.

Remarks

The System.Threading.Monitor class controls access to objects by granting a single thread a lock for an object. Object locks provide the ability to restrict access to a block of code, commonly called a critical section. While a thread owns the lock for an object no other thread can acquire the lock for the object. Additionally, the System.Threading.Monitor class can be used to ensure that no other thread can access a section of application code being executed by the lock owner, unless the other thread is executing the code using a different locked object.

The following information is maintained for each synchronized object:

• A reference to the thread that currently holds the lock.
• A reference to a "ready queue", which contains the threads that are ready to obtain the lock.
• A reference to a "waiting queue", which contains the threads that are waiting for notification of a change in the state of the locked object.

The following table describes the actions taken by threads that access synchronized objects:

Action	Description
Enter	Acquires a lock for an object. Also marks the beginning of a critical section. No other thread can enter the critical section unless they are executing the instructions in the critical section using a different locked object. Note: See the Monitor.Enter(object) and Monitor.TryEnter(object) methods.
Wait	Releases the lock on an object in order to permit other threads to lock and access the object. The calling thread waits while another thread accesses the object. Pulse signals (see below) are used to notify waiting threads about changes to an object's state. Note: See Monitor.Wait(object, int, bool) .
Pulse (signal)	Sends a signal to one or more waiting threads. The signal notifies a waiting thread that the state of the locked object has changed, and the owner of the lock is ready to release the lock. The waiting thread is placed in the object's ready queue so that it can eventually receive the lock for the object. Once the thread has the lock, it can check the new state of the object to see if the required state has been reached. Note: See Monitor.Pulse(object) and Monitor.PulseAll(object) .
Exit	Releases the lock on an object. Also marks the end of a critical section protected by the locked object. Note: See Monitor.Exit(object) .

The Monitor.Enter(object) and Monitor.Exit(object) methods are used to mark the beginning and end of a critical section. If the critical section is a set of contiguous instructions, then the lock acquired by the Monitor.Enter(object) method guarantees that only a single thread can execute the enclosed code with the locked object. This facility is typically used to synchronize access to a static or instance method of a class. If an instance method requires synchronized thread access, the instance method invokes the Monitor.Enter(object) and corresponding Monitor.Exit(object) methods using itself (the current instance) as the object to lock. Since only one thread can hold the lock on the current instance, the method can only be executed by one thread at a time. Static methods are protected in a similar fashion using the Type object of the current instance as the locked object.

Note:

The functionality provided by the Monitor.Enter(object) and Monitor.Exit(object) methods is identical to that provided by the C# lock statement.

If a critical section spans an entire method, the locking facility described above can be achieved by placing the System.Runtime.CompilerServices.MethodImplAttribute on the method, and specifying the System.Runtime.CompilerServices.MethodImplOptions.Synchronized option. Using this attribute, the Monitor.Enter(object) and Monitor.Exit(object) statements are not needed. Note that the attribute causes the current thread to hold the lock until the method returns; if the lock can be released sooner, use the System.Threading.Monitor class (or C# lock statement) instead of the attribute.

While it is possible for the Monitor.Enter(object) and Monitor.Exit(object) statements that lock and release a given object to cross member and/or class boundaries, this practice is strongly discouraged.

[Edit]

Requirements

Namespace: System.Threading
Assembly: mscorlib (in mscorlib.dll)
Assembly Versions: 1.0.5000.0, 2.0.0.0