等待可重入锁中的条件 [英] Waiting on a condition in a reentrant lock

问题描述

以下代码摘自条件的JavaDoc:

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();
    }
  } 
}

想象一下 2 个线程，Consumer 和 Producer，一个使用 take，一个 put 放在单个实例上有界缓冲区.

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

假设 Consumer 先行，运行 take()，他锁定 lock，然后在 notEmpty.await 上循环();.

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

现在 Producer 如何在锁定 lock 之后进入 put() 方法，lock 已经由 持有消费者?

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

我在这里错过了什么?当线程正在等待其条件之一时，lock 是否临时释放"?锁的重入性究竟是什么意思?

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?

推荐答案

Lock 和 synchronized 都允许一个线程在等待时放弃锁而另一个线程可以获得锁.要停止等待，线程必须重新获取锁.

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)

来自 条件.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:

• 一些其他线程为此条件调用了signal()方法，而当前线程恰好被选为要唤醒的线程；或
• 其他一些线程为此条件调用signalAll()方法；或
• 其他一些线程中断当前线程，支持线程挂起中断；或
• 发生虚假唤醒".

在所有情况下，在此方法可以返回当前线程之前，必须重新获取与此条件关联的锁.当线程返回时，它保证持有这个锁

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

这篇关于等待可重入锁中的条件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！