-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Workstealing can lead to deadlocks #3945
Comments
marcphilipp
added
theme: concurrency
component: Platform
status: needs-investigation
and removed
status: new
labels
Sep 9, 2024
Idea: We can use a |
leonard84
added a commit
to leonard84/junit5
that referenced
this issue
Sep 11, 2024
The service now checks if the `ExclusiveTask` that should run is executed on a thread that is already executing another task. If this is scenario is detected, it checks if the lock is compatible to the enclosing locks. 1. If compatible, it is executed and marked done 2. If incompatible, it is added to a list of deferred tasks and left unfinished. The deferred tasks will be re-forked afterward. fixes junit-team#3945 Co-authored-by: Marc Philipp <[email protected]>
leonard84
added a commit
to leonard84/junit5
that referenced
this issue
Sep 11, 2024
The service now checks if the `ExclusiveTask` that should run is executed on a thread that is already executing another task. If this is scenario is detected, it checks if the lock is compatible to the enclosing locks. 1. If compatible, it is executed and marked done 2. If incompatible, it is added to a list of deferred tasks and left unfinished. The deferred tasks will be re-forked afterward. fixes junit-team#3945 Co-authored-by: Marc Philipp <[email protected]>
6 tasks
leonard84
added a commit
to leonard84/junit5
that referenced
this issue
Sep 11, 2024
The service now checks if the `ExclusiveTask` that should run is executed on a thread that is already executing another task. If this is scenario is detected, it checks if the lock is compatible to the enclosing locks. 1. If compatible, it is executed and marked done 2. If incompatible, it is added to a list of deferred tasks and left unfinished. The deferred tasks will be re-forked afterward. fixes junit-team#3945 Co-authored-by: Marc Philipp <[email protected]>
leonard84
added a commit
to leonard84/junit5
that referenced
this issue
Sep 11, 2024
The service now checks if the `ExclusiveTask` that should run is executed on a thread that is already executing another task. If this is scenario is detected, it checks if the lock is compatible to the enclosing locks. 1. If compatible, it is executed and marked done 2. If incompatible, it is added to a list of deferred tasks and left unfinished. The deferred tasks will be re-forked afterward. fixes junit-team#3945 Co-authored-by: Marc Philipp <[email protected]>
marcphilipp
added
type: bug
status: in progress
and removed
status: needs-investigation
labels
Sep 13, 2024
4 tasks
marcphilipp
added a commit
that referenced
this issue
Sep 17, 2024
The service now checks if the `ExclusiveTask` that should run is executed on a thread that is already executing another task. If this is scenario is detected, it checks if the lock is compatible to the enclosing locks. 1. If compatible, it is executed and marked done 2. If incompatible, it is added to a list of deferred tasks and left unfinished. The deferred tasks will be re-forked afterwards. Fixes #3945. --------- Co-authored-by: Marc Philipp <[email protected]>
marcphilipp
added a commit
that referenced
this issue
Sep 17, 2024
The service now checks if the `ExclusiveTask` that should run is executed on a thread that is already executing another task. If this is scenario is detected, it checks if the lock is compatible to the enclosing locks. 1. If compatible, it is executed and marked done 2. If incompatible, it is added to a list of deferred tasks and left unfinished. The deferred tasks will be re-forked afterwards. Fixes #3945. --------- Co-authored-by: Marc Philipp <[email protected]>
marcphilipp
pushed a commit
that referenced
this issue
Sep 23, 2024
The service now checks if the `ExclusiveTask` that should run is executed on a thread that is already executing another task. If this is scenario is detected, it checks if the lock is compatible to the enclosing locks. 1. If compatible, it is executed and marked done 2. If incompatible, it is added to a list of deferred tasks and left unfinished. The deferred tasks will be re-forked afterwards. Fixes #3945. --------- Co-authored-by: Marc Philipp <[email protected]> (cherry picked from commit 88f8859)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce
This does not work every time as it is dependent on multiple factors.
./gradlew :spock-specs:test --rerun -Dvariant=3.0 -DjavaVersion=21
What is Broken?
As you can see in these two screenshots we switch from executing
MockSpecInfoAnnotationSpec
toByteBuddyMockFactoryConcurrentSpec
due to workstealing. The problem is thatMockSpecInfoAnnotationSpec
holds a read-lock for theorg.junit.platform.engine.support.hierarchical.ExclusiveResource.GLOBAL_KEY
butByteBuddyMockFactoryConcurrentSpec
needs a write-lock.Context
Deliverables
The text was updated successfully, but these errors were encountered: