Spin Lock Probes

Threads
cannot block in some contexts in the kernel, such as high-level interrupt
context and any context manipulating dispatcher state. In these contexts,
this restriction prevents the use of adaptive locks. Spin locks are
instead used to effect mutual exclusion to critical sections in these contexts.
As the name implies, the behavior of these locks in the presence of contention
is to spin until the lock is released by the owning thread. The three probes
pertaining to spin locks are in Table 18–2.

Table 18–2 Spin Lock Probes

spin-acquire

Hold-event probe that fires immediately after a spin lock is acquired.

spin-spin

Contention-event probe that fires after a thread that has spun on a
held spin lock has successfully acquired the spin lock. If both are enabled, spin-spin fires beforespin-acquire. arg1 for spin-spin contains the spin
time: the number of nanoseconds that were spent in the spin state
before the lock was acquired. The spin count has little meaning on its own,
but can be used to compare spin times.

spin-release

Hold-event probe that fires immediately after a spin lock is released.

Adaptive locks are much more common than spin locks. The following script
displays totals for both lock types to provide data to support this observation.

As this output indicates, over 99 percent of the locks acquired in running
the date command are adaptive locks. It may be surprising
that so many locks are acquired in doing something as
simple as a date. The large number of locks is a natural
artifact of the fine-grained locking required of an extremely scalable system
like the Solaris kernel.