
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><p>Hi Daniel</p><p>I hope you're doing well. I wanted to follow up on a previous message I sent. Since this is my first time contributing to OpenJDK, I realized I might not have communicated the issue clearly, and I wanted to provide more context about the situation I encountered.</p><p>In the <code>put()</code> method of <code>LinkedBlockingQueue</code>, when the queue reaches its capacity, threads block on <code>notFull.await()</code>. For example, if threads T1, T2, T3, and T4 call <code>put()</code> in sequence when the queue is full, they all wait in the <code>notFull.await()</code> state in sequence as expected.</p><p>Normally, when space becomes available in the queue, I would expect the thread that called <code>put()</code> first (T1) to be signaled, allowing it to proceed in FIFO order. However, the issue arises when a new thread, T5, tries to <code>put()</code> at the same time T1 is signaled to proceed.</p><p>In this scenario, both T1 (which was waiting) and T5 (which just arrived) compete for the <code>ReentrantLock</code>. This competition can lead to T5 acquiring the lock first, allowing it to perform the <code>put()</code> operation before T1, despite T1 having waited the longest. As a result, T1 experiences "starvation," and the order becomes T2, T3, T4, and finally T1, which breaks the expected FIFO order.</p><p>In the test code I provided, if you remove the capacity limit of the queue, the mentioned issue does not occur, and the test passes successfully. You can confirm this by using the <code>new LinkedBlockingQueue<>()</code> constructor without any capacity-related options.</p><p>In a previous discussion, there was a suggestion to synchronize the <code>sequenceNumber</code> and <code>queue.put()</code> using an external lock. However, my intention was to simulate a scenario where T1, T2, T3, and T4 all block in the <code>await()</code> state after sequentially attempting <code>put()</code>. I wanted to observe how they behave when a new thread (T5) arrives and competes for the lock.</p><p>If I use an external lock, T1 will block in the <code>await()</code> state, but T2, T3, and T4 will be waiting for the external lock rather than entering the <code>await()</code> state in <code>put()</code>. This would prevent me from simulating the specific behavior I’m trying to test.</p><p>I’d appreciate your thoughts on whether this behavior (where a newly arriving thread can overtake a waiting thread) is expected or if it’s worth further investigation. As this is my first attempt to contribute to OpenJDK, I’m eager to learn from the process and would love to help resolve the issue if necessary.</p><p>Also, since English is not my first language, I hope my previous emails didn’t come across as rude or unclear. If they did, I sincerely apologize, as it was never my intention to be disrespectful. I’m still learning how to communicate effectively in this space, and I appreciate your understanding and patience.</p><p>Thank you for your time and guidance.</p><p>Best regards,</p><p>Kim Minju</p><div><br><blockquote type="cite"><div>2024. 9. 4. 오후 9:35, Daniel Fuchs <daniel.fuchs@oracle.com> 작성:</div><br class="Apple-interchange-newline"><div><div>Hi Kim,<br><br>On 04/09/2024 12:50, 김민주 wrote:<br><blockquote type="cite">In the original approach, I intended for each thread to call |put|, confirm that it has entered the waiting state, and then allow the next thread to put the next sequence value and also enter the waiting state. This approach was designed to simulate a situation where the queue is already full and each thread has to wait in line for space to become available.<br></blockquote><br>The problem with that is that you would still need to ensure that each<br>thread calls `put` in order, and for that, you would still need<br>external synchronization.<br><br>I am not an expert in java.util.concurrent, but it feels like the<br>fix you had in mind would not buy you much.<br><br>best regards,<br><br>-- daniel<br><br></div></div></blockquote></div><br></body></html>