Readers/writer locks enforce a policy of allowing multiple readers or a single writer — but not both — to be in a critical section. These locks are typically used for structures that are searched more frequently than they are modified and for which there is substantial time in the critical section. If critical section times are short, readers/writer locks will implicitly serialize over the shared memory used to implement the lock, giving them no advantage over adaptive locks. See rwlock ( 9F ) for more details on readers/writer locks.
The probes pertaining to readers/writer locks are in Table 18–4. For each probe, arg0
contains a pointer to the krwlock_t
structure that represents the adaptive lock.
Table 18.4. Readers/Writer Lock Probes
|
Hold-event probe that fires immediately after a readers/writer lock is acquired. |
|
Contention-event probe that fires after a thread that has blocked on a held readers/writer lock has reawakened and has acquired the lock. |
|
Hold-event probe that fires after a thread has successfully upgraded a readers/writer lock from a reader to a writer. Upgrades do not have an associated contention event because they are only possible through a non-blocking interface, rw_tryupgrade ( TRYUPGRADE.9F ) . |
|
Hold-event probe that fires after a thread had downgraded its ownership of a readers/writer lock from writer to reader. Downgrades do not have an associated contention event because they always succeed without contention. |
|
Hold-event probe that fires immediately after a readers/writer lock is released. |