随笔-性能分析-lock overhead

IBM Locking overhead
IBM - Waiting for locks
kernel doc - lock stat
Q: lock wait time and cpu wait time

IBM Locking overhead

https://www.ibm.com/docs/pt/aix/7.2?topic=locks-locking-overhead

Requesting locks, waiting for locks, and releasing locks add processing overhead.

A program that supports multiprocessing always does the same lock and unlock processing, even though it is running in a uniprocessor or is the only user in a multiprocessor system of the locks in question.
When one thread requests a lock held by another thread, the requesting thread may spin for a while or be put to sleep and, if possible, another thread dispatched. This consumes processor time.
The existence of widely used locks places an upper bound on the throughput of the system.

For example, if a given program spends 20 percent of its execution time holding a mutual-exclusion lock, at most five instances of that program can run simultaneously, regardless of the number of processors in the system.

In fact, even five instances would probably never be so nicely synchronized as to avoid waiting for one another (see Multiprocessor throughput scalability).

IBM - Waiting for locks

https://www.ibm.com/docs/pt/aix/7.2?topic=locks-waiting

When a thread wants a lock already owned by another thread, the thread is blocked and must wait until the lock becomes free.

There are two different ways of waiting:

Spin locks are suitable for locks that are held only for very short times. It allows the waiting thread to keep its processor, repeatedly checking the lock bit in a tight loop (spin) until the lock becomes free. Spinning results in increased CPU time (system time for kernel or kernel extension locks).
Sleeping locks are suitable for locks that may be held for longer periods. The thread sleeps until the lock is free and is put back in the run queue when the lock becomes free. Sleeping results in more idle time.

Waiting always decreases system performance. If a spin lock is used, the processor is busy, but it is not doing useful work (not contributing to throughput). If a sleeping lock is used, the overhead of context switching and dispatching as well as the consequent increase in cache misses is incurred.

Operating system developers can choose between two types of locks: mutually exclusive simple locks that allow the process to spin and sleep while waiting for the lock to become available, and complex read-write locks that can spin and block the process while waiting for the lock to become available.

Conventions govern the rules about using locks. Neither hardware nor software has an enforcement or checking mechanism. Although using locks has made the AIX® Version 4 "MP Safe," developers are responsible to define and implement an appropriate locking strategy to protect their own global data.

kernel doc - lock stat

https://docs.kernel.org/locking/lockstat.html

      __acquire
          |
         lock _____
          |        \
          |    __contended
          |         |
          |       <wait>
          | _______/
          |/
          |
     __acquired
          |
          .
        <hold>
          .
          |
     __release
          |
       unlock

lock, unlock  - the regular lock functions
__*           - the hooks
<>            - states