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.
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
[core] Implement get or create for lru cache #50347
[core] Implement get or create for lru cache #50347
Changes from all commits
d73db67
3df76db
6c5b7b2
250a581
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
factory function should be taken as const-l value, never moving
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.
forward the key 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.
No you cannot, because
key
is accessed later; if pass-ed key is rvalue we get invalidated access.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 gotcha, with the erase, why not reorder so that this happens after the
if new_count==0: erase(key)
. The whole block is mutex covered anywaysThere 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.
Yes we can, but I usually don't do move / forward operation here, because it's error prone.
Suppose we add more logic in the code block in the future, it's easy to forget to move the forward semantics around.
I would like to defer until we have clang-tidy integrated in our CI, which reports invalid usage like use after move (I heavily rely on clang-tidy to detect inefficiency and illegal access).
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.
as long as the move/forward is the last thing that happens should be ok, and person changing after should be aware, a lot of our code can break if ppl are not aware when adding more logic, but fine either way, mico-opt
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.
Sigh, I forgot about it for a few times, and I heavily rely on static analysis.
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.
use unique lock to lock, and then notify after unlocking at the end so the wait doesn't fail initial lock acquisition
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, I strongly discourage notifying without lock held.
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.
https://en.cppreference.com/w/cpp/thread/condition_variable
https://en.cppreference.com/w/cpp/thread/condition_variable/notify_one
https://en.cppreference.com/w/cpp/thread/condition_variable/notify_all
all three cppreference examples here unlock before notifying and point 3 on the first link notes you can notify after unlock
Can look at the paragraph on notify_one doc, describes pros and cons of both. Here we're not in the situation where the wait succeeding would cause the cv to be invalidated.
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 the link, checking the code again. I think we can unlock right before cv notification, but you need to reorder code and unlock right before the last line, TBH I don't see too much value.
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.
note not necessary? creation_iter not even in scope 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.
Are you sure?
creation_iter
is just several line above.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.
The comment here is used to explain why we cannot access value via the iterator created before.
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.
ya it's created in the block with unique_lock, not this one
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.
It's created in L213, still valid 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.
why does CreationToken have to be boxed in a shared ptr?
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.
What's your suggestion? I don't think there's other ways.
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.
You cannot use raw value, since token is not copiable;
you cannot use unique pointer, because you don't know which thread is accessing the last reference count.
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 think it might be possible to use unique_ptr, since last thread accessing is the one erasing and you can copy out val before, but ya not worth it this is safer
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.
Unique pointer is also not possible, inside token there's cond var and mutex which are not copiable.