Skip to content
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

[#778] core(feat): Support Tree lock #1264

Merged
merged 48 commits into from
Feb 1, 2024
Merged

Conversation

yuqi1129
Copy link
Contributor

What changes were proposed in this pull request?

Add the tree-like locks to enhance performance.

Why are the changes needed?

Add the tree-like locks to enhance performance.

Fix: #778

Does this PR introduce any user-facing change?

N/A

How was this patch tested?

UT, TestLockManager

@yuqi1129 yuqi1129 marked this pull request as draft December 26, 2023 15:13
@yuqi1129 yuqi1129 marked this pull request as ready for review January 5, 2024 09:18
@yuqi1129 yuqi1129 self-assigned this Jan 8, 2024
@yuqi1129
Copy link
Contributor Author

@jerryshao
Could you take time to review it and then I can make corresponding modifications?

@yuqi1129
Copy link
Contributor Author

@jerryshao
I have made the following modifications:

  1. Let's reduce the eviction time from one day to five minutes.
  2. Every minute, we trigger the lock cleaning process. If a tree node has not been visited for five minutes, it will be removed.
    During the drop procedure, we will try to obtain the write lock to ensure synchronization issues.

Additionally, I will add a new issue to reuse tree locks to reduce memory pressure.


// Handle self node.
if (treeNode.getReference() == 0) {
synchronized (parent) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic for cleaning nodes should be placed in TreeLockNode. TreeLockManager should only be responsible for selecting the TreeLockNode nodes that need to be cleaned, that is, those with a refcount of 0.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to verify the child reference count in the synchronization block, it's not feasible to use a synchronized method here.

/** Unlock the tree lock. */
public void unlock() {
if (lockType == null) {
throw new IllegalStateException("We must lock the tree lock before unlock it.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need throw Exception on unlock function. If the user code throw exception when get TreeLock but not lock. the finally code block should call unlock.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just defensive programming. We can make sure that users will not call it before lock

@yuqi1129
Copy link
Contributor Author

yuqi1129 commented Feb 1, 2024

@jerryshao
All has been resolved.

@jerryshao
Copy link
Contributor

@diqiu50 you can go ahead if you think fine.

Copy link
Contributor

@diqiu50 diqiu50 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jerryshao
Copy link
Contributor

Thanks all for the contribution. I'm going to merge this.

@jerryshao jerryshao merged commit 513d591 into apache:main Feb 1, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Introduce the fine-grained tree lock structure.
3 participants