[e-cvs] cvs commit: e/doc/elib/concurrency event-loop.html
markm@eros.cs.jhu.edu
markm@eros.cs.jhu.edu
Sat, 5 Jan 2002 13:17:00 -0500
markm 02/01/05 13:16:59
Modified: doc/elib/concurrency event-loop.html
Log:
message from Darius
Revision Changes Path
1.14 +76 -11 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.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- event-loop.html 2001/11/15 05:08:02 1.13
+++ event-loop.html 2002/01/05 18:16:59 1.14
@@ -61,8 +61,8 @@
<li>Optional: Add a message dispatch mechanism. Pure lambda calculus is
great at defining one-method objects, but your users want to create
objects that respond to several different types of request. E provides
- for this directly in the kernel, but Scheme, KeyKOS, and EROS show that
- it need not be primitive.
+ for this directly in the kernel, but Actors, Scheme, KeyKOS, and EROS
+ show that it need not be primitive.
<p>
</li>
<li>Add object-local mutable memory and side-effects. Bob can now retain
@@ -99,8 +99,9 @@
we have to come to terms with these issues. Solutions that enable us,
not only to avoid confusing ourselves with our own side-effects, but
to create computation that can interact with an ongoing concurrent world,
- are termed concurrency-control (ref ?? on Transformational vs. Reactive
- computation).
+ are termed concurrency-control. [See also <a href="http://citeseer.nj.nec.com/context/3757/0">On
+ the development of reactive systems</a> by Harel and Pnueli for a similar
+ distinction between <i>transformational</i> and <i>reactive</i> systems.]
<p>
</li>
</ol>
@@ -125,7 +126,7 @@
for organizing large scale economic activity parallels the rationale for
encapsulation in object-oriented systems: to provide a domain (an object’s
encapsulation boundary) in which an agent (the object) can execute plans
- (the object’s methods) that use of resources (an object’s private state),
+ (the object’s methods) that use resources (an object’s private state),
where the proper functioning of these plans depends on these resources
not being used simultaneously by conflicting plans. By dividing up the
resources of society (the state of a computational system) into separately
@@ -135,10 +136,9 @@
<P ALIGN="left">Concurrency introduces a new kind of plan-interference:
plan interleaving. Pre-object sequential programs got into trouble just
from changes to assumptions between one procedure call and the next. While
- a procedure call is in progress, the delicacy of the assumptions in the
- air is often much greater. Concurrency means other procedures executing
- simultaneously can interfere with these delicate assumptions. A simple
- example in Java:
+ a procedure call is in progress, the delicacy of assumptions in the air
+ is often much greater. Concurrency means other procedures executing simultaneously
+ can interfere with these delicate assumptions. A simple example in Java:
<P ALIGN="left">
<blockquote>
<pre>public class CounterExample {
@@ -151,11 +151,11 @@
</blockquote>
<P ALIGN="left">The code compiled from <code>myCounter++</code> makes micro-assumptions.
It reads the value of <code>myCounter</code> into a register, increments
- the register, and writes the new value back out. In two threads call <code>incr()</code>
+ the register, and writes the new value back out. If two threads call <code>incr()</code>
simultaneously, one may overwrite the effect of the other, breaking the
counter.
<P ALIGN="left">A plan with a stale assumption may proceed to cause damage
- because its proper functioning depended on facts which are no longer true.
+ because its proper functioning depends on facts which are no longer true.
Classically, the consistency problem is phrased in terms of preserving
object invariants, but it is better to focus on avoiding stale assumptions.
Since the plan assumptions most likely to be broken by plan interleaving
@@ -236,6 +236,71 @@
supposed to resolve it, you forget to call "<code>resolve</code>"
in all applicable cases. Of course, actual lost signal bugs may be arbitrarily
more complicated than this.</p>
+ <h1>Further Discussion</h1>
+ <p>The following <a href="http://lambda.weblogs.com/discuss/msgReader$2404?mode=day">message</a>
+ by Darius Bacon is a good summary of some further points, with links in
+ its header to a discussion of this topic on the "Lambda" weblog,
+ and links in its body to some good messages on this topic on our own e-lang
+ list.</p>
+ <table cellpadding="24">
+ <tr>
+ <td bgcolor="#FFFFFF">
+ <h2>Re: E - secure,distributed, pure OOP and p2p scripting language</h2>
+ <table cellpadding="0" cellspacing="0" border="0">
+ <tr>
+ <td><b>Author:</b></td>
+ <td width="15" rowspan="6"> </td>
+ <td><a href="http://lambda.weblogs.com/profiles/$darius@accesscom.com">Darius
+ Bacon</a></td>
+ <td width="30" rowspan="6"> </td>
+ <td rowspan="5"></td>
+ </tr>
+ <tr>
+ <td><b>Posted:</b></td>
+ <td>1/4/2002; 10:36:20 PM</td>
+ </tr>
+ <tr>
+ <td><b>Topic:</b></td>
+ <td><a href="http://lambda.weblogs.com/discuss/msgReader$2361?mode=topic" class="dmTopicLink">E
+ - secure,distributed, pure OOP and p2p scripting language</a></td>
+ </tr>
+ <tr>
+ <td><b>Msg #:</b></td>
+ <td><a href="http://lambda.weblogs.com/discuss/msgReader$2404?mode=topic" class="dmMessageNumberLink">2404</a>
+ (in response to <a href="http://lambda.weblogs.com/discuss/msgReader$2361?mode=day">2361</a>)</td>
+ </tr>
+ <tr>
+ <td><b>Prev/Next:</b></td>
+ <td><a href="http://lambda.weblogs.com/discuss/msgReader$2403?mode=day" class="dmPreviousMessageLink">2403</a>/<a href="http://lambda.weblogs.com/discuss/msgReader$2405?mode=day" class="dmNextMessageLink">2405</a></td>
+ </tr>
+ <tr>
+ <td><b>Reads:</b></td>
+ <td>18</td>
+ </tr>
+ </table>
+ <br>
+ The referenced tutorial is aimed at typical working programmers; I
+ think language hackers would get more out of the main erights.org
+ site. This particular issue is discussed at <a href="http://erights.org/elib/concurrency/event-loop.html">http://erights.org/elib/concurrency/event-loop.html</a>
+ and pages linked from there.
+ <p> I think the claim of eliminating deadlock bugs is like the claim
+ functional languages make to eliminate side-effect bugs. You can
+ still write code such that the same kind of interference occurs
+ (in both cases), but the language leads you naturally away from
+ it. If this analogy is right, using event-loop concurrency instead
+ of threads should be a good idea a lot of the time even in languages
+ that don't support it, just like avoiding side effects can improve
+ your C code. Zooko wrote about his Mojo Nation experiences along
+ those lines: <a href="http://www.eros-os.org/pipermail/e-lang/2001-July/005410.html">http://www.eros-os.org/pipermail/e-lang/2001-July/005410.html</a>
+ Jonathan Rees seems to be the first to make this analogy: <a href="http://www.eros-os.org/pipermail/e-lang/2001-August/005585.html">http://www.eros-os.org/pipermail/e-lang/2001-August/005585.html</a>
+ <p> I've never written any concurrent code in E, so my own opinion
+ isn't worth much. Mark Miller gave a list of other relevant posts:
+ <a href="http://www.eros-os.org/pipermail/e-lang/2001-May/005287.html">http://www.eros-os.org/pipermail/e-lang/2001-May/005287.html</a>
+ <a href="http://www.eros-os.org/pipermail/e-lang/2001-July/005418.html">http://www.eros-os.org/pipermail/e-lang/2001-July/005418.html</a>
+ <a href="http://www.eros-os.org/pipermail/e-lang/2001-July/005427.html">http://www.eros-os.org/pipermail/e-lang/2001-July/005427.html</a>
+ </td>
+ </tr>
+ </table>
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
</TR>