On Thu, 26 May 2022 22:27:15 GMT, Leonid Mesnik wrote:
>> Need to use proper synchronization.
>>
>> The CyclicBarriers might move the thread to WAITING state but not BLOCKED.
>> So it should not confuse existing checks.
>
> Leonid Mesnik has updated the pull request incrementally with one
> Need to use proper synchronization.
>
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So
> it should not confuse existing checks.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
fix
-
On Wed, 25 May 2022 23:04:50 GMT, Leonid Mesnik wrote:
>> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line
>> 100:
>>
>>> 98: while (thread.getState() != Thread.State.BLOCKED) {
>>> 99: Thread.sleep(10);
>>> 100: if (thread.getState()
On Wed, 25 May 2022 21:18:24 GMT, master-code-java
wrote:
>> Need to use proper synchronization.
>>
>> The CyclicBarriers might move the thread to WAITING state but not BLOCKED.
>> So it should not confuse existing checks.
>
>
On Tue, 24 May 2022 19:52:57 GMT, Leonid Mesnik wrote:
> Need to use proper synchronization.
>
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So
> it should not confuse existing checks.
test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line
On Tue, 24 May 2022 19:52:57 GMT, Leonid Mesnik wrote:
> Need to use proper synchronization.
>
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So
> it should not confuse existing checks.
Marked as reviewed by alanb (Reviewer).
-
PR:
On Tue, 24 May 2022 19:52:57 GMT, Leonid Mesnik wrote:
> Need to use proper synchronization.
>
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So
> it should not confuse existing checks.
Marked as reviewed by cjplummer (Reviewer).
-
PR:
On Tue, 24 May 2022 19:52:57 GMT, Leonid Mesnik wrote:
> Need to use proper synchronization.
>
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So
> it should not confuse existing checks.
Yes I think that's nice - the two competing Threads own their first lock and
Need to use proper synchronization.
The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So
it should not confuse existing checks.
-
Commit messages:
- 8287200
Changes: https://git.openjdk.java.net/jdk/pull/8874/files
Webrev:
