Lines Matching full:lock
37 <para><link linkend="hg-manual.lock-orders">
38 Potential deadlocks arising from lock
56 use of the LOCK instruction prefix.
107 reader-writer lock arguments, and vice
151 Thread #1 unlocked a not-locked lock at 0x7FEFFFA90
155 Lock at 0x7FEFFFA90 was first observed
173 <sect1 id="hg-manual.lock-orders" xreflabel="Lock Orders">
174 <title>Detected errors: Inconsistent Lock Orderings</title>
176 <para>In this section, and in general, to "acquire" a lock simply
177 means to lock that lock, and to "release" a lock means to unlock
210 lock, the graph is updated, and then checked to see if it now contains
218 Thread #1: lock order "0x7FEFFFAB0 before 0x7FEFFFA80" violated
221 Required order was established by acquisition of lock at 0x7FEFFFAB0
224 followed by a later acquisition of lock at 0x7FEFFFA80
241 Thread #6: lock order "0x6010C0 before 0x601160" violated
299 protect <varname>var</varname> with a lock of type
427 <para>The obvious fix is to use a lock to
507 the lock.</para>
528 mutex unlock-lock pairs. However, since a semaphore can be posted
657 a mutex? If so, you need to lock and unlock the mutex at both
832 lock(mx) lock(mx)
965 <para>When enabled (the default), Helgrind performs lock order
967 of lock order errors reported can become annoying, particularly
969 it helpful to disable lock order checking.</para>
1090 the lock order acquisition graph</para>
1096 lock or unlock event</para>
1168 <listitem><para>For lock order errors, print the complete lock
1184 <listitem><para>Don't update the lock-order graph, and don't check
1185 for errors, when a "try"-style lock operation happens (e.g.
1188 acquire the lock, resulting in the caller going off and doing Plan
1190 generate false lock-order errors and confuse users.</para>
