Redundant wakeups in priority rw_lock_s_unlock_func()

Bug #1240044 reported by Laurynas Biveinis on 2013-10-15
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server
Laurynas Biveinis
Laurynas Biveinis

Bug Description

The current priority rw_lock_s_unlock_func() implementation has some design misunderstanding in it:

 if (lock_word == 0) {

  /* A waiting next-writer exists, either high priority or
  regular. Wake up the first waiter in this order: 1) high
  priority next-writer; 2) high priority X waiters; 3) high
  priority S waiters; 4) regular priority next-waiter. This
  allows high priority requests to overtake an already-waiting
  regular priority next-waiter. */
  if (lock->high_priority_wait_ex_waiter) {

   lock->high_priority_wait_ex_waiter = 0;
   /* Note that we do not have a separate high priority
   next-waiter event. There can be only one such waiter,
   here we already know it's high priority, no
   regular-priority wakeup may happen. */
  } else if (lock->high_priority_x_waiters) {

  } else if (lock->high_priority_s_waiters) {

  } else {


It is impossible with the current implementation, contrary to what the 1st comment says, for a high-priority X or S waiter, to overtake a low-priority next-writer, as the current S unlock already results in X-locked lock word for the next-waiter, whatever its priority is. Thus the high_priority_x_event and high_priority_s_event wakeups are redundant, although benign.

Related branches

tags: added: xtradb
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers