Waiting on a condition in a reentrant lock

Question

The following code is taken from the JavaDoc of Condition:

class BoundedBuffer {   final Lock lock = new ReentrantLock();   final Condition notFull  = lock.newCondition();    final Condition notEmpty = lock.newCondition();     final Object[] items = new Object[100];   int putptr, takeptr, count;    public void put(Object x) throws InterruptedException {     lock.lock();     try {       while (count == items.length)          notFull.await();       items[putptr] = x;        if (++putptr == items.length) putptr = 0;       ++count;       notEmpty.signal();     } finally {       lock.unlock();     }   }    public Object take() throws InterruptedException {     lock.lock();     try {       while (count == 0)          notEmpty.await();       Object x = items[takeptr];        if (++takeptr == items.length) takeptr = 0;       --count;       notFull.signal();       return x;     } finally {       lock.unlock();     }   }  } 

Imagine 2 threads, Consumer and Producer, one using take, one put on a single instance of BoundedBuffer.

Let's say Consumer goes first, runs take() in which he locks the lock and now loops on notEmpty.await();.

How can now Producer possibly get into the put() method past locking the lock, which is already held by the Consumer?

What am I missing here? Is the lock "temporarily released" while the thread is waiting on one of its conditions? And what does the reentrancy of the lock mean, exactly?

Answer 1

Both Lock and synchronized allow a thread to give up the lock when waiting and another thread can obtain the lock. To stop waiting, a thread have to re-acquire the lock.

Note: They don't release it fully and if you take a stack trace you can have multiple threads which appear to be holding the lock at once, but at most one of them will be running (the rest will be blocking)

From Condition.await()

The lock associated with this Condition is atomically released and the current thread becomes disabled for thread scheduling purposes and lies dormant until one of four things happens:

• Some other thread invokes the signal() method for this Condition and the current thread happens to be chosen as the thread to be awakened; or
• Some other thread invokes the signalAll() method for this Condition; or
• Some other thread interrupts the current thread, and interruption of thread suspension is supported; or
• A "spurious wakeup" occurs.

In all cases, before this method can return the current thread must re-acquire the lock associated with this condition. When the thread returns it is guaranteed to hold this lock

Answer 2

As far as re-entrancy, this means that a thread that holds a certain lock can re-acquire the same lock again. If this wasn't so, a synchronized method would not be able to call another synchronized method of the same object.

Re-entrancy is not involved in the understanding of your problem.