Hi Archie, and Viktor
Thank you very much for your response and for referencing the test case I
shared earlier.
I can confirm that the test case is accurate, and the issue lies in the
explanation I provided below it. Upon reflection, I realized that certain parts
of my explanation were incorre
ack.
Thanks again for your time and consideration. I truly appreciate the
opportunity to engage with you and learn through this process.
Best regards,
Minju Kim
> 2024. 9. 11. 오후 1:33, 김민주 작성:
>
> Hi Archie and Viktor,
>
> I apologize for the delay in my response.
>
&g
ks for the details.
>
> So to summarize:
> Kim is saying that "Interpretation B" is how it actually works.
> Viktor is saying that "Interpretation A" is how it actually works.
> Do I have that right?
>
> -Archie
>
> P.S. Viktor: my apologies for misspelling
olds T1 and T2 to T10.]
This is how I currently understand the situation.
If there are any mistakes in my understanding, I would greatly appreciate your
clarification.
Best Regards,
Kim Minju
> 2024. 9. 8. 오전 3:34, Archie Cobbs 작성:
>
> Hi Kim,
>
> On Sat, Sep 7
and willingness to listen to my
thoughts, despite my imperfect understanding. Thank you so much for your time
and insights.
Best regards,
Kim Minju
> 2024. 9. 7. 오전 1:02, 김민주 작성:
>
> Dear Viktor,
>
> I hope this email finds you well. First and foremost, thank you for providing
.
>
> I've re-read ReentrantLock and AQS, and from my understanding on the logic
> the Condition's place in the wait queue should be maintained, which means
> that T3 shouldn't be able to "barge". (tryLock() is documented to allow
> barging)
>
> Le
t ABQ works as expected.
>
> Cheers,
> √
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------
> *From:* Archie Cobbs
> *Sent:* Thursday, 5 September 2024 21:23
> *To:* Viktor Klang
> *Cc:* 김민주 ; Daniel FUC
re-libs-dev on behalf of
> Daniel Fuchs
> *Sent:* Thursday, 5 September 2024 14:11
> *To:* 김민주
> *Cc:* 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
ace, and I appreciate your understanding and patience.
Thank you for your time and guidance.
Best regards,
Kim Minju
> 2024. 9. 4. 오후 9:35, Daniel Fuchs 작성:
>
> Hi Kim,
>
> On 04/09/2024 12:50, 김민주 wrote:
>> In the original approach, I intended for each thread to call
ter approach
this challenge. Are there alternative methods to verify the atomic execution of
`put` and the subsequent waiting state, while still maintaining as much
external control as possible? Your expertise in this area would be greatly
appreciated.
Best regards,
Kim Minju
> 2024. 9. 4.
// restore the sequence
> var restored = sequenceGenerator.decrementAndGet();
> assert token == restored;
> }
> } finally {
> lock.unlock();
> }
>
> });
&
Hello core-libs-dev team,
My name is Kim Minju, and I have investigated a potential issue with both
ArrayBlockingQueue and LinkedBlockingQueue implementations when handling
high contention scenarios. While I am not entirely certain whether this is
a bug or expected behavior,
I would like to share
12 matches
Mail list logo
