Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-14176

Clean up use of state_lock locks in live restore

    • Type: Icon: Technical Debt Technical Debt
    • Resolution: Unresolved
    • Priority: Icon: Minor - P4 Minor - P4
    • None
    • Affects Version/s: None
    • Component/s: Live Restore
    • Storage Engines, Storage Engines - Persistence
    • 5
    • StorEng - 2025-04-25

      This is a follow on from WT-14040. Motivating comment thread is here.

      The live restore code checks if the thread already owns the lock via a

      bool reentrant = __wt_spin_owned(session, &lr_fs->state_lock);
      

      call, however other areas of the code base pass a `locked` argument into the function. We should review whether we can pass a `locked` flag into the functions instead of using the reentrant check.

      If this is possible we could also look at chaning the state_lock from a spinlock to a read-write lock, as this will allow concurrent read accesses for a small speed boost.

            Assignee:
            backlog-server-storage-engines [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            andrew.morton@mongodb.com Andrew Morton
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: