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: 김민주 <miiiinj...@gmail.com> Sent: Thursday, 5 September 2024 16:01 To: Viktor Klang <viktor.kl...@oracle.com> Cc: Daniel FUCHS <daniel.fu...@oracle.com>; core-libs-dev@openjdk.org <core-libs-dev@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.kl...@oracle.com<mailto:viktor.kl...@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-r...@openjdk.org<mailto:core-libs-dev-r...@openjdk.org>> on behalf of Daniel Fuchs <daniel.fu...@oracle.com<mailto:daniel.fu...@oracle.com>> Sent: Thursday, 5 September 2024 14:11 To: 김민주 <miiiinj...@gmail.com<mailto:miiiinj...@gmail.com>> Cc: core-libs-dev@openjdk.org<mailto:core-libs-dev@openjdk.org> <core-libs-dev@openjdk.org<mailto:core-libs-dev@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, >
