-
Notifications
You must be signed in to change notification settings - Fork 10.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
refactor: make LocalCache
not use synchronized
to detect recursive loads (#6845)
#6851
Closed
cortlepp
wants to merge
3
commits into
google:master
from
cortlepp:fix/6845-localcache-no-synchronized
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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.
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.
Thanks for putting this together!
Would it make sense to check the
valueReference
instead ofe.getValueReference()
? I ask because I discovered during testing that the current code has a race: It checkse.getValueReference() instanceof LoadingValueReference
, and then it castse.getValueReference()
toLoadingValueReference
, but the firste.getValueReference()
call might return a loading reference and the second a completed reference.One way to fix that is to call
e.getValueReference()
only once (e.g.,checkRecursiveLoad(key, e.getValueReference());
). But it would seem easier and less fragile to usevalueReference
if that's correct.The worst thing that I can think of about using
valueReference
is that we might check the loading thread unnecessarily (in the case that the reference completed between our earlierisLoading()
check and this one). But that doesn't seem like a significant worry.It actually looks like we could change
waitForLoadingValue
to require aLoadingValueReference
instead of a plainValueReference
: The code already checks this above, so we could just perform a cast before the call instead of a conditional cast here.I have pretty well talked myself into trying this :) I'll report back the results. But please do speak up if I'm missing anything!
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.
Concretely: https://github.com/google/guava/pull/6857/files#diff-98cf5b8d5ed981e94f4c745137a9b4ac3d0e896d0471cfb4e3baf85928c5053d
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.
No your right I think (and the race could have definitely become a problem, good catch!). Just getting the
ValueReference
directly and not from the entry also seems much more straightforward in general, I think I must have overlooked that it's already present as a method parameter.I am a bit worried about changing the method signature to
LoadingValueReference
though. Although I don't see it creating any immediate problems in the code, it feels weird that we are inferring the "is loading" information both from the type and by calling the method. Thus far I think the code relies on calling the method, not the type (this test p.e sets the loading property without being of typeLoadingValueReference
, and when overlooking the code I didn't see anyinstanceof
/ typecasts forLoadingValueReference
but quite a lot of calls toisLoading()
). I'm not sure if it's a good idea to introduce two ways of checking for this property.Of course we at least need to check the type before retrieving the loading thread, but we could do it so that if the value
isLoading()
but is not of typeLoadingValueReference
we simply omit the recursion check (since we don't have a choice) but otherwise continue as usual, without throwing aClassCastException
.I don't generally like that we rely on
isLoading()
instead of the type, but since we seem to be doing it everywhere else I think we should not make an exception here.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.
Oh, good catch! I had convinced myself that
LoadingValueReference
was the only type for whichisLoading()
was true, but I had neglected to look at the tests. I agree that the current setup is a little weird and also that it's not worth fighting against. I'll update my version and retest.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 suppose that another option is to pull
getLoadingThread()
up intoValueReference
and have it returnnull
in the non-loading case. But it's probably safest to keep a clear delineation between the prodLoadingValueReference
, which has the invariants thatisLoading()
is alwaystrue
andgetLoadingThread()
is always non-null, and whatever it is that the test implementation does, which at present does not have such invariants :))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.
OK, back to your approach, just using
valueReference
instead, in https://github.com/google/guava/pull/6857/files#diff-98cf5b8d5ed981e94f4c745137a9b4ac3d0e896d0471cfb4e3baf85928c5053dThere 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.
All right, let me know how when you find out anything new 👍.