CODEWITHSUNDEEP
c#multithreading
Paul M
Paul M

Reputation: 23

Producer-Consumer example, both in lock(this) block

I was looking at Example 2 on this msdn page about Thread synchronization with Monitor.Pulse().

A Cell object is created and passed to both the producer and the consumer objects. 

Cell cell = new Cell( );
CellProd prod = new CellProd(cell, 20);
CellCons cons = new CellCons(cell, 20);

A thread is created for each of those two

Thread producer = new Thread(new ThreadStart(prod.ThreadRun));
Thread consumer = new Thread(new ThreadStart(cons.ThreadRun));

The ThreadRun in each case being a loop that calls Cell.ReadFromCell() or Cell.WriteToCell() depending on consumer/producer. For example, the producer does this

public void ThreadRun( )
{
  for(int looper=1; looper<=quantity; looper++)
     cell.WriteToCell(looper);  // "producing"
}

The bit I don't understand is that in each of these methods they start with a

lock(this)

And since it was the same Cell object (ie, the 'this' in the above lock statement) passed to both, I would have thought that only one thread could be in this section of code at a time. Yet from Monitor.Pulse() and Monitor.Wait() code that follows it looks like both threads are in those sections at the same time. If one had the lock and hit a Monitor.Wait() then the other thread could never Pulse because it is blocked waiting for the lock.

I'm guessing there is a simple solution and I have misunderstood something, from my tests with running the code it looks like both threads are in their critical sections at the same time, so the lock(this) isn't doing what I was under the impression it should do.

Upvotes: 2

Views: 977

Answers (1)

Jon Skeet
Jon Skeet

Reputation: 1500855

The thing you're missing is that Monitor.Wait(this) will release the lock on this until it's woken up. So yes, your consumer thread looks like it's in the lock and therefore owns it, but really it's temporarily released it.

From the docs:

When a thread calls Wait, it releases the lock on the object and enters the object's waiting queue. The next thread in the object's ready queue (if there is one) acquires the lock and has exclusive use of the object. All threads that call Wait remain in the waiting queue until they receive a signal from Pulse or PulseAll, sent by the owner of the lock. If Pulse is sent, only the thread at the head of the waiting queue is affected. If PulseAll is sent, all threads that are waiting for the object are affected. When the signal is received, one or more threads leave the waiting queue and enter the ready queue. A thread in the ready queue is permitted to reacquire the lock.

Upvotes: 8

Related Questions