<div dir="ltr"><div dir="ltr"><p class="gmail-">Hi Viktor, hi Daniel,</p><p class="gmail-">Thank you both for your helpful feedback and insightful explanations.</p><p class="gmail-">Viktor, your point about <code>Condition::await()</code> and spurious wakeups has given me a lot to think about. I now better understand why strict FIFO ordering is challenging, especially given the possibility of spurious wakeups causing threads to reacquire locks unpredictably.</p><p class="gmail-">Daniel, your explanation regarding fairness in locks and how it relates to thread scheduling has clarified why strict fairness can be difficult to achieve in practice. It’s especially helpful to know that even with fairness enabled, other factors can affect thread progression, as explained in the documentation you provided.</p><p class="gmail-">While I understand that these challenges are inherent to multithreading and some level of unpredictability is inevitable, I’m still wondering whether it’s appropriate for the implementation to allow new threads attempting to <code>put()</code> to compete with threads that are already in the <code>await()</code> state. It feels like this could lead to unintended contention and disruption of expected behavior. Wouldn't it make more sense to ensure that threads already blocked in <code>await()</code> have priority over newly arriving threads?</p><p class="gmail-">I’m curious to know if you think this approach could be an improvement, or if this is one of those unavoidable trade-offs in concurrent system design.</p><p class="gmail-">Thank you again for your time and expertise. I’m learning a lot through this process, and I really appreciate your guidance.</p><p class="gmail-">Best regards,<br>Kim Minju</p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2024년 9월 5일 (목) 오후 10:35, Viktor Klang <<a href="mailto:viktor.klang@oracle.com">viktor.klang@oracle.com</a>>님이 작성:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3712022757277240001">




<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Hi,</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
I'd also like to add here that Condition::await() is allowed to return spuriously, leading to a reacquisition, and a subsequent release waiting to be woken again, which would change the order from potentially being "next to run" to becoming "last to run". At
 least this is the case as I read the implementation logic.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div id="m_-8677047069010105461Signature" style="color:inherit">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Cheers,<br>
√</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<b><br>
</b></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<b>Viktor Klang</b></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Software Architect, Java Platform Group<br>
Oracle</div>
</div>
<div id="m_-8677047069010105461appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_-8677047069010105461divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> core-libs-dev <<a href="mailto:core-libs-dev-retn@openjdk.org" target="_blank">core-libs-dev-retn@openjdk.org</a>> on behalf of Daniel Fuchs <<a href="mailto:daniel.fuchs@oracle.com" target="_blank">daniel.fuchs@oracle.com</a>><br>
<b>Sent:</b> Thursday, 5 September 2024 14:11<br>
<b>To:</b> 김민주 <<a href="mailto:miiiinju00@gmail.com" target="_blank">miiiinju00@gmail.com</a>><br>
<b>Cc:</b> <a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a> <<a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a>><br>
<b>Subject:</b> Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>Hi Kim,<br>
<br>
On 05/09/2024 06:10, 김민주 wrote:<br>
> If I use an external lock, T1 will block in the |await()| state, but T2, <br>
> T3, and T4 will be waiting for the external lock rather than entering <br>
> the |await()| state in |put()|. This would prevent me from simulating <br>
> the specific behavior I’m trying to test.<br>
<br>
I understand. But my point is that waking up callers in exactly the<br>
same order they have have arrived may not be of much interest since you<br>
would need first to ensure that they arrive in exactly that<br>
proper order.<br>
<br>
> I’d appreciate your thoughts on whether this behavior (where a newly <br>
> arriving thread can overtake a waiting thread) is expected or if it’s <br>
> worth further investigation. As this is my first attempt to contribute <br>
> to OpenJDK, I’m eager to learn from the process and would love to help <br>
> resolve the issue if necessary.<br>
<br>
I am not sure how strong the "fairness" constraint is.<br>
<br>
Typically for monitors, when a thread is signaled after the monitor<br>
is released "it competes in the usual manner with other threads for the <br>
right to synchronize on the object"<br>
<a href="https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Object.html#wait(long,int)" target="_blank">https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Object.html#wait(long,int)</a><br>
<br>
That said, we're speakings of locks here - and the only thing I<br>
could find (in ReentrantLock) is that if fairness is set, then<br>
"under contention, locks favor granting access to the<br>
longest-waiting thread", but note that "fairness of locks does<br>
not guarantee fairness of thread scheduling. Thus, one of many<br>
threads using a fair lock may obtain it multiple times in<br>
succession while other active threads are not progressing and<br>
not currently holding the lock."<br>
<a href="https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html" target="_blank">https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html</a><br>
<br>
I am not an expert of the java.util.concurrent package, and<br>
hopefully others in this list will be able to provide more<br>
insights.<br>
<br>
> Also, since English is not my first language, I hope my previous emails <br>
> didn’t come across as rude or unclear. If they did, I sincerely <br>
> apologize, as it was never my intention to be disrespectful. I’m still <br>
> learning how to communicate effectively in this space, and I appreciate <br>
> your understanding and patience.<br>
<br>
Hey - you're welcome - and I found your emails quite clear.<br>
But English is not my first language either ;-)<br>
<br>
best regards,<br>
<br>
-- daniel<br>
<br>
> <br>
> Thank you for your time and guidance.<br>
> <br>
> Best regards,<br>
> <br>
<br>
</div>
</span></font></div>
</div>

</div></blockquote></div></div>