Understanding InnoDB Lock‑Wait Timeout Thread and Its Processing Logic

1. Timeout Check Thread

InnoDB has a background thread named ib_srv_lock_to that performs a timeout check once per second to see if any lock‑wait transactions have timed out.

When a transaction enters a lock‑wait state, it notifies this thread, which also serves as the dead‑lock detection thread.

The thread receives notifications to trigger an immediate dead‑lock check; however, it only performs a timeout check if at least one second has passed since the previous check.

2. Finding Timed‑Out Transactions

The timeout check scans the memory region pointed to by the lock module’s waiting_threads array, which contains srv_max_n_threads slots, each holding a srv_slot_t object with transaction information, start‑wait time, and timeout values.

The last_slot pointer marks the slot after the last used slot; slots beyond it are free.

To locate timed‑out transactions, the thread iterates from the first slot up to the slot before last_slot , examining each used slot’s suspend_time and wait_timeout fields.

Compute the difference between the current time and suspend_time .

If the difference exceeds wait_timeout , the lock‑wait has timed out and requires further handling.

3. Handling Timeout Logic

For each timed‑out lock‑wait, the thread removes the corresponding lock structures from various internal lists.

If the wait was on a row lock, the thread deletes the lock from the transaction’s trx_locks list and from the rec_hash array.

If the wait was on a table lock, the thread deletes the lock from the transaction’s trx_locks list and from the table’s locks list.

Whether the transaction is automatically rolled back on timeout is controlled by the system variable innodb_rollback_on_timeout (default false). When true, the transaction rolls back, and the lock structures must be removed to avoid orphaned locks.

4. Notifying Timed‑Out Transactions

When a transaction enters lock‑wait, it occupies a free slot and, if the slot is newly used, an event object is stored in the slot’s event field.

After processing the timeout logic, the thread triggers this event, notifying the waiting transaction that its lock‑wait has timed out.

The transaction then records the wait time in the slow‑query log, generates a timeout error message, and, if innodb_rollback_on_timeout is true, rolls back.

5. Summary

Two participants are involved in lock‑wait timeout: the active timeout check thread and the passive waiting transaction.

The main workflow of the timeout check thread is:

Iterate over slots between waiting_threads and last_slot .

For each used slot, determine whether the lock‑wait has timed out.

If timed out, execute the timeout handling logic.

Notify the corresponding transaction.

After receiving the notification, the transaction performs its own cleanup, completing the lock‑wait lifecycle.