[External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

[김민주]

Hi Viktor, hi Daniel,

Thank you both for your helpful feedback and insightful explanations.

Viktor, your point about Condition::await() 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.

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.

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
put() to compete with threads that are already in the await() 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 await() have priority over newly arriving threads?

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.

Thank you again for your time and expertise. I’m learning a lot through
this process, and I really appreciate your guidance.

Best regards,
Kim Minju

2024년 9월 5일 (목) 오후 10:35, Viktor Klang <viktor.klang at oracle.com>님이 작성:

> Hi,
>
> 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.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> Daniel Fuchs <daniel.fuchs at oracle.com>
> *Sent:* Thursday, 5 September 2024 14:11
> *To:* 김민주 <miiiinju00 at gmail.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation
> in BlockingQueue under high contention and suggestion for fair mode in
> ArrayBlockingQueue and LinkedBlockingQueue
>
> Hi Kim,
>
> On 05/09/2024 06:10, 김민주 wrote:
> > If I use an external lock, T1 will block in the |await()| state, but T2,
> > T3, and T4 will be waiting for the external lock rather than entering
> > the |await()| state in |put()|. This would prevent me from simulating
> > the specific behavior I’m trying to test.
>
> I understand. But my point is that waking up callers in exactly the
> same order they have have arrived may not be of much interest since you
> would need first to ensure that they arrive in exactly that
> proper order.
>
> > 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.
>
> I am not sure how strong the "fairness" constraint is.
>
> Typically for monitors, when a thread is signaled after the monitor
> is released "it competes in the usual manner with other threads for the
> right to synchronize on the object"
>
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Object.html#wait(long,int)
>
> That said, we're speakings of locks here - and the only thing I
> could find (in ReentrantLock) is that if fairness is set, then
> "under contention, locks favor granting access to the
> longest-waiting thread", but note that "fairness of locks does
> not guarantee fairness of thread scheduling. Thus, one of many
> threads using a fair lock may obtain it multiple times in
> succession while other active threads are not progressing and
> not currently holding the lock."
>
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html
>
> I am not an expert of the java.util.concurrent package, and
> hopefully others in this list will be able to provide more
> insights.
>
> > 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.
>
> Hey - you're welcome - and I found your emails quite clear.
> But English is not my first language either ;-)
>
> best regards,
>
> -- daniel
>
> >
> > Thank you for your time and guidance.
> >
> > Best regards,
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240905/23276430/attachment-0001.htm>