ZanderXu commented on PR #6762: URL: https://github.com/apache/hadoop/pull/6762#issuecomment-2562240142
> I know this PR is phase 1 work: split global lock into fslock and bmlock. We should ensure the lock order: bmlock cannot occur in front of fslock. Can we add some restrictions or check mechanisms to avoid getting a bmlock before fslock? Thanks, @zhengchenyu . This is a good idea. The check mechanism is theoretically feasible (verifying whether the BMLock is already held when acquiring the FSLock). However, due to lock reentry, this approach introduces complexity and negatively impacts the performance. Let's briefly consider some common scenarios: 1. A thread acquires the FS read lock for the first time. 2. A thread acquires the FS write lock for the first time. 3. A thread holding the Global read lock reenters the FS read lock (already holding the BM read lock). 4. A thread holding the Global write lock reenters the FS read lock (already holding the BM write lock). 5. A thread holding the Global write lock reenters the FS write lock (already holding the BM write lock). In scenarios 3, 4, and 5, the BM lock already held is normal when acquiring FS lock. However, in scenarios 1 and 2, the BM lock already held is abnormal when acquiring FS lock. Indeed, lock reentry can also be checked, but I think it’s unnecessary as it’s overly complicated. We can use other methods to detect deadlock issues. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
