Uploaded image for project: 'MariaDB Server'
  1. MDEV-5492

Reduce usage of LOCK_open: TABLE::in_use

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Fix Version/s: 10.0.9
    • Component/s: None
    • Labels:
      None

      Description

      tc_acquire_table and tc_release_table are critical sections of table cache. Among other things, they update TABLE::in_use:
      tc_acquire_table - table->in_use= current_thd
      tc_release_table - table->in_use= 0

      Normally table->in_use is only accessed/modified by thread that owns this table instance, which means access to this variable doesn't really need to be synchronized.

      There are a few exception though when foreign threads may read this variable:

      • TABLE_SHARE::visit_subgraph() (MDL deadlock detector): called after marking table(s) old and purging unused table instances, thus tc_acquire_table() must never change in_use (because there is nothing to acquire); tc_release_table() must be fixed not to change in_use while table is in all_tables list. Otherwise no synchronization needed.
      • kill_delayed_threads_for_table(): mostly same as for TABLE_SHARE::visit_subgraph().
      • list_open_tables(): no synchronization needed, unsafe access is acceptable.
      • print_cached_tables() (debug only): synchronization needed.
      • check_unused() (debug only): remove this function, it was supposed to check unused_tables, which was eliminated by MDEV-5388 Closed .
      • tdc_remove_table() (debug only): no extra synchronization needed, protected by exclusive MDL.

      There are a few options how we can synchronize access to this variable:

      • mutex (can be complex, MDL deadlock detecter needs recursive lock)
      • rwlock
      • atomic spinlock (requires much less memory than mutex/rwlock)

        Attachments

          Issue links

            Activity

              People

              • Assignee:
                svoj Sergey Vojtovich
                Reporter:
                svoj Sergey Vojtovich
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 4 hours
                  4h