Signal Streams in Blocked State

Question

I took the following points from the API , and I would like to know the difference between the two following points:

• Pending flows are signaled in FIFO order.

• The blocking order for repeated requests for threads returning from wait methods is the same as for threads that initially acquire a lock, which is not specified by default, but for honest locks it supports those threads that have been waiting for the longest.

It is associated with the Condition class, which is usually returned by the ReentrantLock .newCondition() method, and I quote it a bit, explaining the difference between the Condition methods and the usual control methods of the Object class.

"Waiting for flows is signaled in FIFO order." I think that as long as the lock is created either honestly or not, the fact that pending threads are signaled in FIFO order is completely inappropriate, right? because one way or another they were built, fair or not, which decides how they are queued.

Just ask for confirmation.

Thanks in advance.

Answer 1

Below are the answers to your questions:

1. Real streams are transmitted in FIFO order.

When we call the wait condition () method, the thread goes into the idle state, the above statement refers to how these threads are signaled in the idle state. Therefore, if the flows T1 went into a standby state before T2, T1 will be signaled before T2.

2. The order of locking ordering for threads returning from wait methods is the same as for threads initially acquiring a lock, which is not specified by default, but for honest locks it supports those threads that were waiting for the longest one.

In continuation to the above statement, when a pending stream signal is signaled, it tends to re-lock. Although the above statement says that T1 will be signaled to T2, but when it comes to reaquiring locks, the re-capture order uses concepts defined by Lock. Thus, it depends on how the Lock object was created. When creating a Lock, you could specify an equity parameter:

ReentrantLock(boolean fair)

If yes, then this parameter is used, if not, then the default lock behavior occurs, you can learn more about ReentrantLock locks on this

There may be more explanation for these statements, just tried to best explain my understanding here. Hoping he could clarify.

Greetings !!

Answer 2

As long as the lock is created either honestly or not, the fact that the waiting threads are signaled in FIFO order does not matter at all, does it? Because one way or another they were built, fair or not, which decides how they are queued.

I think this is relevant.

Consider a scenario in which T1 and T2 wait under condition C (while waiting for T1 longer than T2), T3 works inside the monitor, and T4 waits for its initial blocking. T3 signals C and leaves the monitor unlocking the lock. Suppose that no side awakening occurs.

If the lock is fair , T4 will definitely get a lock to T1, but the fact that pending flows are signaled in FIFO order will guarantee that T1 will get a lock to T2.

In addition, if the lock is not fair , we cannot say which thread will receive the lock first between T1 and T4, but again, the fact that the waiting threads are signaled in FIFO order ensures that T1 receives the lock before T2, if there are no other no signals will occur until T1 receives a lock (for example, if T1 is responsible for the next alarm).

Answer 3

I think the source code can give us more information on how it works. ReentrantLock.newCondition () returns ConditionObject in AbstractQueuedSynchronizer . Here is the source code link AQS source code .

1. Real streams are transmitted in FIFO order.

There are two queues in AbstractQueuedSynchronizer .

One to wait for a lock (just call the wait wait queue), you will see two mutable head and tail variables in the AbstractQueuedSynchronizer Description , and the equity parameter will affect the behavior of this queue. When you select a new ReentrantLock and call to acquire , AQS will call FairSync tryAcquire to check if the current thread is the first thread waiting for a lock wait queue, see hasQueuedPredecessors .

The other queue is the signal queue in the ConditionObject definition, you will see two variables firstWaiter and lastWaiter . When it waits , a node will add queues to the tail, and when the signal is called, the node will be removed from the head and added to the lock waiting queue before recquire lock.Add to the lock waiting queue does not mean that it will be woken up, but Lock.unlock () will called after a signal that waiters wake up, see unparkSuccessor .

2. The order of locking ordering for threads returning from wait methods is the same as for threads initially acquiring a lock, which is not specified by default, but for honest locks it supports those threads that were waiting for the longest one.

Awakening from the wait method does not mean locking, it will call acquireQuedued to re-lock the lock and it will be possible to park again. In my understanding, the order of the initial acquisition of the lock is the same as the order of the call is expected , as well as the order of the call to acquireQueued , which confused me , but for honest locks, the threads that were waiting for the longest are preferred. . When you wake up from waiting , in my opinion, this will be the first thread in the waiting queue for locking, When you call, getQuedued and check p == head && & & tryAcquire (arg) , lock fair or not has no effect.

Hope this helps, and let me if I am wrong.