[e-cvs] cvs commit: e/doc/elib/concurrency event-loop.html
markm@eros.cs.jhu.edu
markm@eros.cs.jhu.edu
Mon, 27 Aug 2001 15:33:00 -0400
markm 01/08/27 15:33:00
Modified: doc/elib/concurrency event-loop.html
Log:
more deadness cases
Revision Changes Path
1.8 +30 -1 e/doc/elib/concurrency/event-loop.html
Index: event-loop.html
===================================================================
RCS file: /cvs/e/doc/elib/concurrency/event-loop.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- event-loop.html 2001/05/09 05:00:41 1.7
+++ event-loop.html 2001/08/27 19:33:00 1.8
@@ -201,11 +201,40 @@
afford to write will have too few locks to be confident in its safety.
By contrast, you can easily write event-loop programs in which you have
high confidence in its safety and its liveness.
- <h2 ALIGN="left">Other Liveness Issues</h2>
+ <h2 ALIGN="left"><a name="deadness"></a>Other Liveness Issues</h2>
+ <p ALIGN="left">Besides deadlock, there are other kinds of bugs which can
+ prevent a program from making progress. While E doesn't have classic deadlock,
+ it still has these vulnerabilities, some of which resemble deadlock.</p>
<h3 ALIGN="left">Livelock -- infinite loops steal the vat's thread</h3>
+ <p ALIGN="left">An infinite loop prevents this incarnation of a vat from
+ ever again making progress, just as it would prevent a conventional thread
+ from making progress. As with conventional threads, it does not prevent
+ other vats (threads) from making progress. Unfortunately, since each E
+ object is in only one vat, livelocking a vat does lock up all objects
+ within a vat. (This would be analogous to livelocking a thread that holds
+ a <code>synchronized</code> lock on several objects.)</p>
+ <p ALIGN="left">Fortunately, for a persistent vat, this locks up only the
+ vat incarnation, not the vat itself. By killing the livelocked incarnation,
+ the vat can roll back to its last checkpoint, be reincarnated, and proceed
+ from there. Unfortunately, this doesn't guarantee that it won't livelock
+ again. </p>
+ <p ALIGN="left">Turing's halting problem demonstrates the ultimate unsolvability
+ of this problem.</p>
<h3 ALIGN="left"><a href="../../elang/concurrency/epimenides.html">Datalock</a>
-- recursive data definition with no bottom</h3>
+ <p ALIGN="left">This also includes when-catches that are "waiting"
+ (posted as callbacks for) promises that the other would resolve.</p>
<h3 ALIGN="left">Gridlock -- messages need space to move</h3>
+ <p ALIGN="left">Technically, this looks like a classic deadlock, but it's
+ caused specifically by lack of outgoing buffers. The distinction between
+ deadlock and gridlock? If more buffer space would have caused you not
+ to have locked up <i>yet</i>, then it's gridlock rather than deadlock.</p>
+ <h3 ALIGN="left">Lost Signal -- overslept, forgot to set the alarm</h3>
+ <p>An <a href="http://www.eros-os.org/pipermail/e-lang/2001-August/005629.html">example</a>,
+ due to Mark Seaborn (thanks!): If you have a when-catch "waiting"
+ (posted as a callback) for a promise to be resolved, but in the code that's
+ supposed to resolve it, you forget to call "<code>resolve</code>"
+ in all applicable cases.</p>
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
</TR>