Lines Matching full:lock
28 <dt><span class="sect1"><a href="hg-manual.html#hg-manual.lock-orders">7.3. Detected errors: Inconsistent Lock Orderings</a></span></dt>
60 <li class="listitem"><p><a class="link" href="hg-manual.html#hg-manual.lock-orders" title="7.3.?Detected errors: Inconsistent Lock Orderings">
61 Potential deadlocks arising from lock
74 use of the LOCK instruction prefix.
113 reader-writer lock arguments, and vice
153 Thread #1 unlocked a not-locked lock at 0x7FEFFFA90
157 Lock at 0x7FEFFFA90 was first observed
169 <div class="sect1" title="7.3.?Detected errors: Inconsistent Lock Orderings">
171 <a name="hg-manual.lock-orders"></a>7.3.?Detected errors: Inconsistent Lock Orderings</h2></div></div></div>
172 <p>In this section, and in general, to "acquire" a lock simply
173 means to lock that lock, and to "release" a lock means to unlock
199 lock, the graph is updated, and then checked to see if it now contains
205 Thread #1: lock order "0x7FEFFFAB0 before 0x7FEFFFA80" violated
208 Required order was established by acquisition of lock at 0x7FEFFFAB0
211 followed by a later acquisition of lock at 0x7FEFFFA80
226 Thread #6: lock order "0x6010C0 before 0x601160" violated
274 protect <code class="varname">var</code> with a lock of type
386 <p>The obvious fix is to use a lock to
456 the lock.</p></li>
473 mutex unlock-lock pairs. However, since a semaphore can be posted
579 a mutex? If so, you need to lock and unlock the mutex at both
732 lock(mx) lock(mx)
839 <dd><p>When enabled (the default), Helgrind performs lock order
841 of lock order errors reported can become annoying, particularly
843 it helpful to disable lock order checking.</p></dd>
944 <li class="listitem"><p>For lock order errors, print the complete lock
957 <li class="listitem"><p>Don't update the lock-order graph, and don't check
958 for errors, when a "try"-style lock operation happens (e.g.
961 acquire the lock, resulting in the caller going off and doing Plan
963 generate false lock-order errors and confuse users.</p></li>
