-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Non blocking ReservedThreadExecutor #6535
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Never block waiting for reserved thread. Dump reserved thread stack if it does not make the rendezvous
…95-ReservedThreadExecutor
fix warnings
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
avoid waiting 1s
If a reserved thread does not rendezvous, put it back on the bottom of the stack.
Even more paranoid checks: + test if an missed offer was for a thread that removed itself from the stack + test if a reserved thread is already on the stack before adding it.
Even more paranoid checks: + try to poll after remove to check for race in remove
Even more paranoid checks: + try to poll after remove to check for race in remove
This is a new approach to #6495. A call to offer must never block, nor even yield, since to do so give an opportunity for the allocated CPU core to change, defeating the whole purpose of the class. There is also some reasonable level of diagnostic warnings if a reserved thread misses too many offers consecutively, based on tracking the state of the reserved thread.
Use MAX_VALUE rather than -1 as the stopped marker value.
Remove the stack data structure entirely. ReservedThreads all poll the same SynchronousQueue and tryExecute does a non blocking offer.
Added test for busy shrinking
Remember last time we hit zero reserved threads
lorban
reviewed
Jul 23, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the simplification a lot!
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Outdated
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Outdated
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Outdated
Show resolved
Hide resolved
updates from review
@lorban updated |
@sbordet nudge? |
lorban
requested changes
Jul 26, 2021
jetty-util/src/test/java/org/eclipse/jetty/util/thread/ReservedThreadExecutorTest.java
Show resolved
Hide resolved
jetty-util/src/test/java/org/eclipse/jetty/util/thread/ReservedThreadExecutorTest.java
Outdated
Show resolved
Hide resolved
updates from review
@sbordet nudge |
sbordet
requested changes
Jul 27, 2021
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Outdated
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Outdated
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Outdated
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Outdated
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Outdated
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Greg Wilkins <gregw@webtide.com>
Signed-off-by: Greg Wilkins <gregw@webtide.com>
…:eclipse/jetty.project into jetty-9.4.x-6495-ReservedThreadExecutor3
updates from review
simplified tryExecute
updates from review
updates from review
sbordet
requested changes
Jul 28, 2021
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Outdated
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Outdated
Show resolved
Hide resolved
jetty-util/src/main/java/org/eclipse/jetty/util/thread/ReservedThreadExecutor.java
Outdated
Show resolved
Hide resolved
updates from review
sbordet
approved these changes
Jul 28, 2021
lorban
approved these changes
Jul 28, 2021
gregw
added a commit
that referenced
this pull request
Jul 28, 2021
A call to offer must never block, nor even yield, since to do so give an opportunity for the allocated CPU core to change, defeating the whole purpose of the class. There is also some reasonable level of diagnostic warnings if a reserved thread misses too many offers consecutively, based on tracking the state of the reserved thread. Remove the stack data structure entirely. ReservedThreads all poll the same SynchronousQueue and tryExecute does a non blocking offer. Added test for busy shrinking Remember last time we hit zero reserved threads Co-authored-by: Simone Bordet <simone.bordet@gmail.com>
gregw
added a commit
that referenced
this pull request
Jul 29, 2021
A call to offer must never block, nor even yield, since to do so give an opportunity for the allocated CPU core to change, defeating the whole purpose of the class. There is also some reasonable level of diagnostic warnings if a reserved thread misses too many offers consecutively, based on tracking the state of the reserved thread. Remove the stack data structure entirely. ReservedThreads all poll the same SynchronousQueue and tryExecute does a non blocking offer. Added test for busy shrinking Remember last time we hit zero reserved threads Co-authored-by: Simone Bordet <simone.bordet@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is yet another alternative fix for #6495 replacing #6496
The stack is removed entirely and all the reserved threads poll in parallel on the same synchronous queue.
The
tryExecute
semantic is simply to do a non-blocking offer to the queue which will either succeed or fail, and no further action is required.The
size
andpending
counts are important to keep the capacity correct.The reserved threads are added as beans, but only for the purposes of dumping.
The reserved threads track their state to make the dumps more meaningful.
The only issue with losing the stack is that it may prevent reserved threads idling out as load might be shared over all the reserved threads rather than just the most recent.
However, there are other strategies that could be applied to deal with that (eg looking at recent minimum size before re-polling).