signalAll在条件接口对对象的notifyAll [英] signalAll in Condition interface vs notifyAll in object

问题描述

1）昨天只有我问这个问题条件vs等待通知机制

2）我想编辑相同的内容，并在我的问题中添加几个ifs，但是因为它可能变得繁琐，包含足够的文本，

3）对于我的帖子的上下文，其url在第1点给出），考虑4个线程，P1，T1和P2，T2作用于单个数据结构S。

4）我试图再次利用Condition interface over wait notify的优点。

5）考虑代码

  final Lock lock = new ReentrantLock 
条件c1 = lock.newCondition（）; 
条件c2 = lock.newCondition（）; 
条件c3 = lock.newCondition（）; 
条件c4 = lock.newCondition（）; 6）考虑P1，T1使用c1，c2（在标准的await（）/ signalAll中） （）方式）。考虑P2，T2使用c3，c4（在标准的await（）/ signalAll（）方式）我们分别说put，take，put1，take1方法。
 
 
 
 7）当我做c1.signalAll（），将只有等待/由于condition1 的线程将接收信号。我有意义吗？
 
 
 
 8）考虑一个等待/通知机制来实现相同的说法，
  private static final Object lock = new Object（）; 
同步（锁定）
  
考虑put，take，put1，take1，在任何一个条件实现上执行lock.notifyAll（），甚至由于其他条件等待/打开的线程将接收通知。真的吗 ？。这是我们可以算作使用wait / notify over Condition机制的缺点吗？
解决方案
 条件类是内在条件队列的概括（通过 Object.wait ， Object.notify 和 Object.notifyAll ）。
 
 
 
 Brian Goetz的Java并发实践[p.306-307] 
 
 
内在条件队列有几个缺点。每个内在锁只能有一个关联的条件队列，这意味着在类BoundedBuffer中，多个线程可能在同一条件队列上等待不同的条件谓词，最常见的锁定模式涉及暴露条件队列对象。这两个因素使得不可能执行使用notifyAll的统一服务器要求。如果要使用多个条件谓词编写并发对象，或者希望对条件队列的可见性进行更多的控制，则显式Lock和Condition类提供了一种比内部锁和条件队列更灵活的替代方法。
 
 
 
条件与单个锁相关联，就像条件队列与单个固有锁相关联一样; [...]正如Lock提供比内部锁定更丰富的特性集，Condition提供比内在条件队列更丰富的特性集：每个锁多个等待集，可中断和不间断条件等待，基于期限等待，以及选择公平或不公平排队。
 
 
 
1) Yesterday only I asked this question Condition vs wait notify mechanism

2) I wanted to edit the same and add a few ifs to my question, but because it could have become cumbersome and contained enough text to disinterest and baffle the reader, I thought of asking a new question here.

3) With context of my post whose url is given in point number 1), consider a case of 4 threads, P1,T1 and P2,T2 acting on a single data structure 'S'.

4) I am trying to again draw the advantages of using Condition interface over wait notify.

5) Consider the code 
final Lock lock = new ReentrantLock();
Condition c1 = lock.newCondition();
Condition c2 = lock.newCondition();
Condition c3 = lock.newCondition();
Condition c4 = lock.newCondition();
6) Consider P1,T1 making use of c1,c2 (in a standard await()/signalAll() manner). Consider P2,T2 making use of c3,c4 (in a standard await()/signalAll() manner) in let's say put,take,put1,take1 methods respectively.

7) When I do c1.signalAll(), will only the threads waiting on/because of condition1 will recieve signal. Do I make sense ?

8) Consider a wait/notify mechanism to implement the same say,
private static final Object lock= new Object();
synchronized(lock)
Consider put,take,put1,take1, so if any thread does a lock.notifyAll() on any one of the condition fulfillment, even the threads waiting for/on because of other conditions will recieve a notification. Is that true ?. Is that something we can count as a disadvantage of using wait/notify over Condition mechanism ?
解决方案
Yes, you are right. The Condition class is a generalization of intrinsic condition queues (the ones which are controlled through Object.wait, Object.notify and Object.notifyAll).

I will quote Brian Goetz`s Java Concurrency in Practice [p.306-307]

  
Intrinsic condition queues have several drawbacks. Each intrinsic lock can have only one associated condition queue, which means that in classes like BoundedBuffer multiple threads might wait on the same condition queue for different condition predicates, and the most common pattern for locking involves exposing the condition queue object. Both of these factors make it impossible to enforce the uniform waiter requirement for using notifyAll. If you want to write a concurrent object with multiple condition predicates, or you want to exercise more control over the visibility of the condition queue, the explicit Lock and Condition classes offer a more flexible alternative to intrinsic locks and condition queues.
  
  
A Condition is associated with a single Lock, just as a condition queue is associated with a single intrinsic lock; [...] And just as Lock offers a richer feature set than intrinsic locking, Condition offers a richer feature set than intrinsic condition queues: multiple wait sets per lock, interruptible and uninterruptible condition waits, deadline-based waiting, and a choice of fair or nonfair queueing.


                        
这篇关于signalAll在条件接口对对象的notifyAll的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！