-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
RxRingBuffer with synchronization #2553
RxRingBuffer with synchronization #2553
Conversation
@@ -34,7 +34,7 @@ | |||
public static RxRingBuffer getSpscInstance() { | |||
if (UnsafeAccess.isUnsafeAvailable()) { | |||
// TODO the SpscArrayQueue isn't ready yet so using SpmcArrayQueue for now |
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.
If SpscArrayQueue is now fixed we can remove this comment.
Here is my perf comparison building on what I did at #2333 (comment):
The degradations of this are incremental and I think worth the correctness. Crazy to me that we can't find a non-blocking approach that performs better than the JVM doing lock-elision. I suggest we move forward with this after cleaning up the comments in the code that are no longer valid. |
Fixes in comments.
Yet another undelrying
Okay. If you feel ready, you can merge it at your will. I'll take care of #2541. |
else if (null != lvElement(lElementBuffer, offset)){ | ||
return false; | ||
} | ||
// if (producerIndex >= producerLookAhead) { |
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.
Any particular reason to keep this commented code?
RxRingBuffer with synchronization
Changed RxRingBuffer to use synchronized blocks for correctness. We are relying here upon biased locking and lock-elision. It gets pretty close to the baseline
Benchmark:
Changes (in respect of 1.x):