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.

Sign up for GitHub

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

Jump to bottom

Fix(levels): Avoid a deadlock when acquiring read locks in levels #1744

Merged
merged 1 commit into from Sep 14, 2021
Merged

Fix(levels): Avoid a deadlock when acquiring read locks in levels #1744

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
18 changes: 16 additions & 2 deletions levels.go
View file
Open in desktop
Expand Up @@ -1120,8 +1120,22 @@ func (s *levelsController) fillTablesL0ToL0(cd *compactDef) bool {
cd.nextRange = keyRange{}
cd.bot = nil

cd.lockLevels()
defer cd.unlockLevels()
// Because this level and next level are both level 0, we should NOT acquire
// the read lock twice, because it can result in a deadlock. So, we don't
// call compactDef.lockLevels, instead locking the level only once and
// directly here.
//
// As per godocs on RWMutex:
// If a goroutine holds a RWMutex for reading and another goroutine might
// call Lock, no goroutine should expect to be able to acquire a read lock
// until the initial read lock is released. In particular, this prohibits
// recursive read locking. This is to ensure that the lock eventually
// becomes available; a blocked Lock call excludes new readers from
// acquiring the lock.
y.AssertTrue(cd.thisLevel.level == 0)
y.AssertTrue(cd.nextLevel.level == 0)
s.levels[0].RLock()
defer s.levels[0].RUnlock()

s.cstatus.Lock()
defer s.cstatus.Unlock()
Expand Down