|
From: <sv...@va...> - 2007-11-05 02:10:32
|
Author: sewardj
Date: 2007-11-05 02:10:33 +0000 (Mon, 05 Nov 2007)
New Revision: 7090
Log:
Last minute mods the the manual.
Modified:
branches/THRCHECK/thrcheck/docs/tc-manual.xml
Modified: branches/THRCHECK/thrcheck/docs/tc-manual.xml
===================================================================
--- branches/THRCHECK/thrcheck/docs/tc-manual.xml 2007-11-05 00:25:53 UTC (rev 7089)
+++ branches/THRCHECK/thrcheck/docs/tc-manual.xml 2007-11-05 02:10:33 UTC (rev 7090)
@@ -327,7 +327,7 @@
</itemizedlist>
<para>Understanding the memory state machine is central to
-understanding Thrcheck's race-detection algorithm. The next two
+understanding Thrcheck's race-detection algorithm. The next three
subsections explain this.</para>
</sect2>
@@ -1227,6 +1227,14 @@
and <computeroutput>http://lkml.org/lkml/2007/10/24/673</computeroutput>.
</para>
</listitem>
+ <listitem><para>Don't update the lock-order graph, and don't check
+ for errors, when a "try"-style lock operation happens (eg
+ pthread_mutex_trylock). Such calls do not add any real
+ restrictions to the locking order, since they can always fail to
+ acquire the lock, resulting in the caller going off and doing Plan
+ B (presumably it will have a Plan B). Doing such checks could
+ generate false lock-order errors and confuse users.</para>
+ </listitem>
</itemizedlist>
|