plockstat Provider

The {{plockstat}} provider makes available probes that can be used to observe the behavior of user-level synchronization primitives including lock contention and hold times. The [{{plockstat}}(1M)|http://docs.sun.com/doc/819-2240/plockstat-1m?a=view] command is a DTrace consumer that uses the {{plockstat}} provider to gather data on user-level locking events.

[Top|#top]
h2. {anchor:CHP-PLOCKSTAT-1} Overview
The {{plockstat}} provider makes available probes for the following types of events:
{section}
{column:width=15%}
_Contention Events_
{column}
{column:width=85%}
These probes correspond to contention on a user-level synchronization primitive, and fire when a thread is forced to wait for a resource to become available. Solaris is generally optimized for the non-contention case, so prolonged contention is not expected; these probes should be used to understand those cases where contention does arise. Because contention is designed to be (relatively) rare, enabling contention-event probes generally doesn't have a serious probe effect; they can be enabled without concern for substantially affecting performance.
{column}
{section}
{section}
{column:width=15%}
_Hold Events_
{column}
{column:width=85%}
These probes correspond to acquiring, releasing or otherwise manipulating a user-level synchronization primitive. As such, these probes can be used to answer arbitrary questions about the way user-level synchronization primitives are manipulated. Because applications typically acquire and release synchronization primitives very often, enabling hold-event probes can have a greater probe effect than enabling contention-event probes. While the probe effect induced by enabling them can be substantial, it is not pathological; they may still be enabled with confidence on production applications.
{column}
{section}
{section}
{column:width=15%}
_Error Events_
{column}
{column:width=85%}
These probes correspond to any kind of anomalous behavior encountered when acquiring or releasing a user-level synchronization primitive. These events can be used to detect errors encountered while a thread is blocking on a user-level synchronization primitive. Error events should be extremely uncommon so enabling them shouldn't induce a serious probe effect.
{column}
{section}

[Top|#top]

|{{mutex-block}}|Contention event probe that fires before a thread blocks on a held mutex. Both {{mutex-block}} and {{mutex-spin}} might fire for a single lock acquisition.|
|{{mutex-spin}}|Contention event probe that fires before a thread begins spinning on a held mutex. Both {{mutex-block}} and {{mutex-spin}} might fire for a single lock acquisition.|
|{{mutex-release}}|Hold event probe that fires immediately after an mutex is released. {{arg1}} contains a boolean value that indicates whether the event corresponds to a recursive release on a recursive mutex.|
|{{mutex-error}}|Error event probe that fires when an error is encountered on a mutex operation. {{arg1}} is the {{errno}} value for the error encountered.|

[Top|#top]

|{{rw-block}}|Contention event probe that fires before a thread blocks while attempting to acquire a lock. If enabled, the {{rw-acquire}} probe or the {{rw-error}} probe will fire after {{rw-block}}.|
|{{rw-release}}|Hold event probe that fires immediately after a reader/writer lock is released|
|{{rw-error}}|Error event probe that fires when an error is encountered during a reader/writer lock operation. {{arg1}} is the {{errno}} value of the error encountered.|

|Module|Private|Private|Unknown|
|Function|Private|Private|Unknown|
|Name|Evolving|Evolving|ISA|
|Arguments|Evolving|Evolving|ISA|
{excerpt:hidden=true}Converted by tech dogg's sgml2wiki on Tue 20 Nov 2007 at 9:25:41 PM{excerpt}