Lines Matching refs:locks

11 The basic object the validator operates upon is a 'class' of locks.
13 A class of locks is a group of locks that are logically the same with
14 respect to locking rules, even if the locks may have multiple (possibly
24 perspective, the two locks (L1 and L2) are not necessarily related; that
108 Unused locks (e.g., mutexes) cannot be part of the cause of an error.
140 Furthermore, two locks can not be taken in inverse order::
146 deadlock - as attempts to acquire the two locks form a circle which
150 operations; the validator will still find whether these locks can be
167 any rule violation between the new lock and any of the held locks.
185 could interrupt _any_ of the irq-unsafe or hardirq-unsafe locks, which
197 locks in this fixed order on each of the objects.
234 Two constructs can be used to annotate and check where and if certain locks
325 sequence of locks taken after each other) only once. A simple stack of
326 held locks is maintained, and a lightweight 64-bit hash value is
344 initialize locks.  These two problems are illustrated below:
349 	that module's locks, but module unloading does not remove old
355 	locks that are not explicitly initialized.  For example,
363 	would place all 8192 locks into a single lock class.
366 	initialize your locks.