-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Get rid of all synchronized
blocks and methods in production code
#1178
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
Changes from all commits
48992f4
f021214
bb3e00e
45ad718
a9e4095
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -245,9 +245,12 @@ private ServerDescription lookupServerDescription(final ServerDescription curren | |
} catch (Throwable t) { | ||
averageRoundTripTime.reset(); | ||
InternalConnection localConnection; | ||
synchronized (this) { | ||
lock.lock(); | ||
try { | ||
localConnection = connection; | ||
connection = null; | ||
} finally { | ||
lock.unlock(); | ||
} | ||
if (localConnection != null) { | ||
localConnection.close(); | ||
|
@@ -311,11 +314,14 @@ private long waitForSignalOrTimeout() throws InterruptedException { | |
|
||
public void cancelCurrentCheck() { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again this looks like it was purposely defensive - any ideas why? Could There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I can't reconstruct the ideas of why
The only thing that matters for this PR is whether Thus, we only need to consider whether it is fine for the code in the block to run concurrently with itself and with the code in the other There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I agree 👍 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if the the intention is to prevent concurrent calls to But if that's the case it still seems unnecessary, as that method should (and does at least for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I don't think it should (even if it does). I'll look into this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Currently, However, if But, there are other reasons in this class why Overall, it is extremely difficult at times to reason about concurrency in the driver, because in many cases the thread-safety and related requirements/guarantees are not documented, especially for internal code. One of the outstanding culprits is TL;RD Thank you for pointing out the problem, the change may indeed introduce issues on top of those that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Agreed. We can and should take opportunities to improve this aspect of the driver.
Perhaps interestingly: this seems a general problem with implementations of AutoCloseable/Closeable. Neither say anything about concurrency in the Javadoc, yet implementations like |
||
InternalConnection localConnection = null; | ||
synchronized (this) { | ||
lock.lock(); | ||
try { | ||
if (connection != null && !currentCheckCancelled) { | ||
localConnection = connection; | ||
currentCheckCancelled = true; | ||
} | ||
} finally { | ||
lock.unlock(); | ||
} | ||
if (localConnection != null) { | ||
localConnection.close(); | ||
|
Uh oh!
There was an error while loading. Please reload this page.