Type Reason ArgumentNullException obj is null. System.Threading.SynchronizationLockException The calling thread does not own the lock for the specified object.
Only the current owner of the lock can signal a waiting object using Pulse.
The thread that currently owns the lock on the specified object invokes this method to signal the next thread in line for the lock. Upon receiving the pulse, the waiting thread is moved to the ready queue. When the thread that invoked Pulse releases the lock, the next thread in the ready queue (which is not necessarily the thread that was pulsed) acquires the lock.
The System.Threading.Monitor class does not maintain state indicating that the Monitor.Pulse(object) method has been called. Thus, if you call Monitor.Pulse(object) when no threads are waiting, the next thread that calls erload:System.Threading.Monitor.Wait blocks as if Monitor.Pulse(object) had never been called. If two threads are using Monitor.Pulse(object) and erload:System.Threading.Monitor.Wait to interact, this could result in a deadlock. Contrast this with the behavior of the System.Threading.AutoResetEvent class: If you signal an System.Threading.AutoResetEvent by calling its EventWaitHandle.Set method, and there are no threads waiting, the System.Threading.AutoResetEvent remains in a signaled state until a thread calls erload:System.Threading.WaitHandle.WaitOne, erload:System.Threading.WaitHandle.WaitAny, or erload:System.Threading.WaitHandle.WaitAll. The System.Threading.AutoResetEvent releases that thread and returns to the unsignaled state.
Note that a synchronized object holds several references, including a reference to the thread that currently holds the lock, a reference to the ready queue, which contains the threads that are ready to obtain the lock, and a reference to the waiting queue, which contains the threads that are waiting for notification of a change in the object's state.
To signal multiple threads, use the Monitor.PulseAll(object) method.