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

Add mechanisms for checking whether a session holds a spinlock

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • WT11.2.0, 7.1.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None

      Summary

      It would be useful to be able to add assertions about whether we own a spin lock, especially for functions that assume that a specific lock is acquired by the caller.

      This ticket is the "mechanisms" subset of WT-10898, including just the actual modifications to the mutex plus the new functionality, without the actual asserts throughout the code—except perhaps for a few examples at most.

      Motivation

      A function that requires a specific lock to be acquired by the caller can start with an assertion verifying that the lock is taken and that it is owned by the current session. This has the following advantages:

      • Code readability: The locking protocol is self-documented in the code.
      • Correctness: The locking protocol is enforced (at least on debug builds).

      Additionally, if a lock knows whether it is currently acquired by the current session, we can simplify clean up at the end of functions by implementing a function that unlocks the spin lock only if it is locked by the current session.

      Suggested approach

      The implementation of this can be quite simple:

      1. Add a session ID field to __wt_spinlock, and clear it in __wt_spin_init.
      2. Set the session ID after acquiring the lock in __wt_spin_lock and __wt_spin_trylock. The lock function can even start with an assert checking that the lock is not currently acquired by the current session.
      3. Clear the session ID just before releasing the lock in __wt_spin_unlock.
      4. Create a function or a macro that checks the value of session ID to the value saved in the struct.

      Alternatively, we can store the pointer to the session itself inside the lock.

      Risks

      This adds more work on the critical path, but it should be only two memory stores, which shouldn't need to be atomic.

            Assignee:
            peter.macko@mongodb.com Peter Macko
            Reporter:
            peter.macko@mongodb.com Peter Macko
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: