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

Thu Sep 5 15:36:20 UTC 2024

Hi Kim,

I'll add some of my personal thoughts on the matter.

What you're typically after when you're reaching for "fair" is not a strict linearizable order (because such order needs external, additional, coordination to be observable), but rather what you want is to avoid the risk of "unbounded unfairness", I'll give an example:

Think of a drinking glass cabinet: If you always put back glasses in front of other glasses when they have been used and cleaned, and you always get glasses from the front—given sufficient number of glasses compared to your glass-needs, you're going to end up with the glasses at the very front showing significant signs of usage where the ones at the back will be brand new and unused.

Or more succinctly: stack-based access patterns easily lead to logarithmic-like usage distributions.

With this in mind, it would be interesting (at least to me!) if you could devise a test which can demonstrate that the "fair" mode of ABQ can lead to unbounded unfairness.

Cheers,
√

Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: 김민주 <miiiinju00 at gmail.com>
Sent: Thursday, 5 September 2024 16:01
To: Viktor Klang <viktor.klang at oracle.com>
Cc: Daniel FUCHS <daniel.fuchs at oracle.com>; 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 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<mailto: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<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com<mailto:daniel.fuchs at oracle.com>>
Sent: Thursday, 5 September 2024 14:11
To: 김민주 <miiiinju00 at gmail.com<mailto:miiiinju00 at gmail.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto: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/70ef4cda/attachment-0001.htm>