yuqi1129 commented on issue #8729: URL: https://github.com/apache/gravitino/issues/8729#issuecomment-3596260363
> Should we explicitly enforce that only the same thread that acquires the lock may call unlock()? Yes, currently the tree lock is only used and wrapped in `TreeLockUtils#doWithTreeLock` and then ignores the issue of the callee problem that all should be done in the same thread. Indeed, we can improve it to adapt to different use scenarios. > If a TreeLock instance is shared across multiple threads, should we add explicit memory barriers for fields like lockType (e.g., declare it volatile or use AtomicReference) There should be no race condition in `TreeLock#lockType` as we will create a new instance every time we try to acquire the lock. > If a RuntimeException occurs while releasing nodes in unlock(), should we still reset lockType = null in a finally block to prevent leaving the TreeLock in an inconsistent state? As we used `ReentrantReadWriteLock` as the element of `TreeLock`, it seems impossible to throw exceptions like `RuntimeException` when calling `ReentrantReadWriteLock#unlock`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
