【问题标题】:Is signal guaranteed to reach thread?信号是否保证到达线程?
【发布时间】:2019-02-13 04:20:14
【问题描述】:

假设我有三个线程,T1, T2, T3、一个锁lockResource 资源上的一些条件cond

T1 获得锁,现在由于某些条件而执行cond.await()T2 获得该锁并执行cond.signal(),然后继续执行lock.unlock(),但有一段时间,T3 也在尝试获取锁,所以它在lock.lock()的行,到底发生了什么?

T2 是否重新获得锁或T3 是否获得它或者它是基于调度程序的随机?

【问题讨论】:

    标签: java multithreading operating-system locking


    【解决方案1】:

    每当发出信号时,其中一个等待线程将被移除,并将被放回入口集中,以便他有机会运行。在 signalAll 方面,所有等待线程将从等待集中移除并放回入口集中,以便它们有机会运行。

    是的,然后调度程序决定从条目集中选择哪个线程。在公平方面,等待时间最长的将首先获得机会。

    很好的解释here

    【讨论】:

      【解决方案2】:

      如果您阅读文档,即ReentrantLock 的 javadoc,它在第 3 段中专门回答了这个问题:

      该类的构造函数接受一个可选的fairness 参数。当设置true 时,在争用下,锁有利于授予对最长等待线程的访问权限。否则,此锁不保证任何特定的访问顺序。

      【讨论】:

      • OTOH,我认为不公平算法比公平算法更轻(更快且内存更少),如果公平无关紧要,那么不公平锁是首选。