<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Archie,<br>
<br>
I should've been more specific—Condition-as-implemented-by-ReentrantLock (in fair mode) provides stronger (for some definition of stronger) semantics that the Condition interface specifies.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Since it's related, I've recently integrated a hardening of AQS and AQLS reacquisition logic in await().</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Given what you presented earlier about the detection of "producer parked" it's likely that the conclusion is that ABQ works as expected.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature" 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="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Archie Cobbs <archie.cobbs@gmail.com><br>
<b>Sent:</b> Thursday, 5 September 2024 21:23<br>
<b>To:</b> Viktor Klang <viktor.klang@oracle.com><br>
<b>Cc:</b> 김민주 <miiiinju00@gmail.com>; Daniel FUCHS <daniel.fuchs@oracle.com>; core-libs-dev@openjdk.org <core-libs-dev@openjdk.org><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>
<div dir="ltr">
<div dir="ltr">
<div>
<div>Apologies in advance if I'm misunderstanding anything...</div>
<div><br>
</div>
</div>
<div>On Thu, Sep 5, 2024 at 2:05 PM Viktor Klang <<a href="mailto:viktor.klang@oracle.com">viktor.klang@oracle.com</a>> wrote:
<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
Thread state polling aside, for as long as Condition::await() is allowed to spuriously wake, FIFO just cannot be "guaranteed".</blockquote>
<div> </div>
<div>What about this statement in the Javadoc for ReentrantLock.newCondition():</div>
<div><br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for
<i>fair</i> locks favors those threads that have been waiting the longest. </blockquote>
<div><br>
</div>
<div>So what you're saying is that a spurious wakeup on a Condition is not the same thing as a spurious signal() on a Condition; if it were, then the above statement would apply and FIFO ordering would be preserved.</div>
<div><br>
</div>
<div>Of course, a spurious wakeup would not find the condition being waited on satisfied unless there was a big coincidence. So an ordering violation that actually mattered should be exceedingly rare.<br>
</div>
<div><br>
</div>
<div>Anyway, this does seem to be a glitch in how things are supposed to work. That is: there can be no guaranteed ordering for Condition waiters when there can be spurious wakeups.</div>
<div><br>
</div>
<div>Maybe this corner case should be documented. Or better yet, fix the bug by requiring Condition to "filter out" spurious wakeups if preserving FIFO ordering (it should be possible).<br>
</div>
<div><br>
</div>
<div>-Archie<br>
</div>
</div>
<br>
<span class="x_gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="x_gmail_signature">Archie L. Cobbs<br>
</div>
</div>
</div>
</body>
</html>