|
From: <sv...@va...> - 2007-11-09 15:46:34
|
Author: sewardj
Date: 2007-11-09 15:46:37 +0000 (Fri, 09 Nov 2007)
New Revision: 7114
Log:
Minor changes.
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-09 15:44:15 UTC (rev 7113)
+++ branches/THRCHECK/thrcheck/docs/tc-manual.xml 2007-11-09 15:46:37 UTC (rev 7114)
@@ -179,7 +179,7 @@
<para>Thrcheck builds a directed graph indicating the order in which
locks have been acquired in the past. When a thread acquires a new
lock, the graph is updated, and then checked to see if it now contains
-a cycle. Presence of a cycle indicates a potential deadlock involving
+a cycle. The presence of a cycle indicates a potential deadlock involving
the locks in the cycle.</para>
<para>In simple situations, where the cycle only contains two locks,
@@ -544,11 +544,12 @@
<para>This program is correct, but using only the mechanisms described
so far, Thrcheck would report an error at
-<computeroutput>var += 4;</computeroutput>. This is because, by that
+<computeroutput>var += 4</computeroutput>. This is because, by that
point, <computeroutput>var</computeroutput> is marked as being in the
-state "shared-modified with a singleton
-lockset <computeroutput>{mx}</computeroutput>". Really, what we want
-is for <computeroutput>var</computeroutput> to return to the parent
+state "shared-modified and protected by the
+lock <computeroutput>mx</computeroutput>", but is being accessed
+without locking. Really, what we want is
+for <computeroutput>var</computeroutput> to return to the parent
thread's exclusive ownership after the child thread has exited.</para>
<para>To make this possible, for every memory location Thrcheck also keeps
|