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> on behalf of Daniel Fuchs <daniel.fu...@oracle.com> Sent: Thursday, 5 September 2024 14:11 To: 김민주 <miiiinj...@gmail.com> Cc: 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 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, >
