Solaris: locks & lockstat

 

Locking

Locks are used to protect critical data structures from simultaneous update access. Locks allows you to update one or a group of variables. Locks can also provide a synchronization mechanism for threads.

 

Locks are used when threads share “writable data”. However, frequent locking is required when a program writes data. There are several locking mechanism available to manage different locking situations.

Sr. #	Lock	Description
1.	Mutex	Ensures only one thread can lock a resource at a time. No other thread can lock the resource until the previous thread releases the resource. A thread performing a read, reads the data that the locking thread last stored. The state of locking thread must be visible to all processors on a multiprocessor system.
2.	Conditional Variable	Associated with a condition. Condition Variables remain in force as long as the condition exists.
3.	Counting Semaphore	Control multiple thread access to a resource. When a thread acquires the resource, the value of the semaphore is decremented.
4.	Multiple-reader, single-writer	Enables several threads to access data. The reader group and the thread that wants to write the data owns the lock.

 

A poor locking design that protects too much data by using one lock can create performance problems by serializing the threads for a long time. To solve locking problems, you must significantly “re-design” the program.

Locking problems:

Performance problems that are related to locking are difficult to identify and usually appear as programs running slower than expected for no obvious reasons.

The following programming errors cause problems with locking:

a.       Contention caused by inappropriate use of locking mechanisms

b.      A deadlock caused by two competing operations

c.       A lock control that is “lost” to the process

d.      A race for resources, which is similar to deadlock situation.

e.      An incomplete implementation of the lock control within the program.

 

“Lockstat” is the tool used to identify locking problems in an application.

 

Example:

# lockstat -H -D 10 sleep 1

 

Adaptive mutex spin: 513 events

Count indv cuml rcnt     nsec Lock                Caller

-------------------------------------------------------------------------

  480   5%   5% 1.00     1136 0x300007718e8       putnext+0x40

  286   3%   9% 1.00      666 0x3000077b430       getf+0xd8

  271   3%  12% 1.00      537 0x3000077b430       msgio32+0x2fc

  270   3%  15% 1.00     3670 0x300007718e8       strgetmsg+0x3d4

  270   3%  18% 1.00     1016 0x300007c38b0       getq_noenab+0x200

  264   3%  20% 1.00     1649 0x300007718e8       strgetmsg+0xa70

  216   2%  23% 1.00     6251 tcp_mi_lock         tcp_snmp_get+0xfc

  206   2%  25% 1.00      602 thread_free_lock    clock+0x250

  138   2%  27% 1.00      485 0x300007c3998       putnext+0xb8

  138   2%  28% 1.00     3706 0x300007718e8       strrput+0x5b8

-------------------------------------------------------------------------

[...]

 

Explanation:

In the above example, the lockstat command monitors the locks user by the “sleep” command. Within its own process as well as the locks obtained for the processes in the kernel. These locks are acquired during system call processing.

Large “indv” with a slow or fast locking time helps in identifying the problem. A module is identified that is causing a problem by referring to the lock name, which is usually prefixed with the module name.

 

Note: the “indv” column shows current event as a percentage of all events.