unknown
1970-01-01 00:00:00 UTC
As context for those new to this thread, earlier I wrote
[...] Doug Barnes first created Original-E, by shoehorning Joule-inspired
concurrency onto a Java base in an intense two week efforts driven by a
business panic, after a contractual dispute between Agorics (creator,
provider, and supporter of Joule, where I was) and Electric Communities
(using Joule to create a decentralized secure virtual reality, where Doug
Barnes was). I only joined E.C. a year or so later, in 1995, whereupon I
took over leadership of the Original-E effort.
The significance of that step cannot be underestimated. Prior to this, all
the Actors and concurrent logic work that I was aware of assumed that, to
get a language with a sensible concurrency control model (e.g., actors or
concurrent logic programming), you had to start with concurrency. After all,
the previous attempts we were aware of adding concurrency to a sequential
language base, including Multilisp btw, but including the earlier efforts of
geniuses like Dijkstra (semaphores) and Hoare (monitors), all ended up
making the shared state concurrency mistake, i.e., shared memory
multithreading with fine grained locking. For the Vulcaneers, this view had
been reinforced at PARC, as the other concurrency crowd there was developing
Cedar, an outgrowth of Mesa, which proceeded to inspire the Modula-Ns, where
very smart people made this mistake everywhere. (Hoare's CSP and
ccam avoided this mistake, but at such a severe loss of expressiveness that
we did not take it seriously.)
Looking at the results of Doug Barnes' two week effort, it was clear that
there was never any necessary conflict all along, but none of us had been
able to see it. The Joule concurrency constructs, grafted onto a sequential
Java base, did not push that base towards shared state concurrency. However,
even by the time I arrived at E.C., the Joule-like concurrency that Doug
added was not quarantined from Java's shared state concurrency, leaving a
mess. (I would argue that Scala today makes the same mistake.)
At E.C., Danfuzz Bornstein and I brought vats to Original-E, finally fully
separating Original-E's Joule-like concurrency from the hazards of Java's
shared state concurrency. In some ways the Original-E vat was based on the
Joule "tank", serving as a unit of preemptive termination and transparent
distribution. But this didn't help regarding concurrency models, as a Joule
tank, like an Actors worker, was still pervasively concurrent internally.
Instead, I realized that an Original-E vat was, in this sense, like a single
big highly-multi-faceted single Joule actor, where each locally exported
object acts as a distinct facet of the vat. In this context, Joule's inner
send became conventional LIFO immediate call-return, which any object within
a vat could only immediate-call other objects within the same vat. Whereas
anyone could do an eventual send to a facet of a vat, i.e., any object
within a vat they had a reference to, which would only queue up on the end
of the queue. The two-ended dequeue nature of Original-E's stack + pending
deliver queue is in this sense a direct reflection of the inner-send fix
that Dean contributed to that first Vulcan paper.
Original-E was to see a local heap of sequential objects as a large
multi-faceted actor, and to realize that exporting a previously unexported
object from within this local heap was like *dynamically* adding a facet to
a Joule actor, which was not possible in Joule. Once I took on this shift of
perspective, much of the rest followed naturally.
The mechanics of Original-E references was still problematic, as Joule's
multichannels did not co-exist with sequentiality all that smoothly,
especially regarding problem reporting. In 1998, when Chip Morningstar
(cc'ed) and I derived E from Original-E, I returned to many aspects of
Xanadu's promise system that Joule had left behind. Sometime in early 1998,
when I sketched the eight hand drawn pages scanned in at <
http://erights.org/e/semantics.html> all this came together into the
reference mechanics of modern E.
--
Cheers,
--MarkM
--0016e64084dee8687304a58990bd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable <div>[+kenneth.kahn, +danfuzz, +douglas (barnes), +ehud.shapiro, +carl, +chip]</div><div><br></div>On Sun, Jun 12, 2011 at 3:54 AM, Constantine Plotnikov <span dir="ltr"><<a href="mailto:***@gmail.com" target="_blank">***@gmail.com</a>></span> wrote:<br> <div class="gmail_quote"><div>[...]�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>It would be interesting to know how this idea of Vat comes to E. I'm also interested whether there are other Actor model implementations (that declare that they such) where asynchronous components could share single event loop.</div> </div></blockquote><div><br></div>On Sun, Jun 12, 2011 at 10:48 AM, Dean Tribble <span dir="ltr"><<a href="mailto:***@e-dean.com" target="_blank">***@e-dean.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
Agreed.�The larger islands of sequential programming in E were quite a benefit for many kinds of programming, and is probably the key insight in [the] E computational model. [...]</blockquote><div><br></div><div>Thanks. To explain how E arrived at this insight, a bit of history. The following is all based on my old flawed memories, so cc'ing various involved people for corrections and gap-filling. For those new to this thread, more context can be found starting at <<a href="http://www.eros-os.org/pipermail/e-lang/2011-June/013865.html" target="_blank">http://www.eros-os.org/pipermail/e-lang/2011-June/013865.html</a>>. To contribute to this thread, please first subscribe at <<a href="http://www.eros-os.org/mailman/listinfo/e-lang" target="_blank">http://www.eros-os.org/mailman/listinfo/e-lang</a>> or your messages will be silently rejected.</div> <div><br></div><div><br></div><div>Ehud Shapiro's 1983 paper "A subset of Concurrent Prolog and its Interpreter" began the field of concurrent logic programming. That same year, Shapiro (cc'ed) and Takeuchi's "Object-oriented programming in concurrent Prolog" showed how to encode actors as a pattern of concurrent logic programming, by reifying the "mailbox" as a stream of incoming messages, provided by convention as a first argument to a goal. In 1987, Ken Kahn, Dean Tribble, Danny Bobrow, and myself formed the Vulcan project at PARC, initially to provide sugar to more directly express actors/objects on top of this concurrent logic programming base.</div> <div><br></div><div>Dean diagnosed and fixed a flaw in an early draft of "Vulcan: Logical Concurrent Objects", and in so doing invented the inner-vs-outer send technique which would later show up in Joule and become so important to our E story below. An outer send would append onto the tail of a stream of messages, adding a new message to be serviced after all previously queued messages. An inner send, it you had the capabilities needed to express it, would prepend a message onto the head of the stream of messages, to be servived ahead of all previously queued messages.</div> <div><br></div><div>Vijay Saraswat (hi Vijay -- it's good to see you here!) joined the Vulcan project soon afterwards. We never really made much use of our sugar, finding it didn't add much convenience and hid too much of the underlying power. And a good thing too. The sugar would have baked in the one-mailbox-per-actor assumption. By programming more directly on the base, we came to realize the power of having a single actor (or concurrent logic programming perpetual process) serve multiple mailboxes. This power is explained well in Ken Kahn's "Objects: A Fresh Look" (the crucial text seems to be in the pages missing between p217 and p220 in <<a href="http://books.google.com/books?id=oiAkSgoiz6EC&lpg=PA207&ots=ShwbQwMNp9&dq=%22objects%20a%20fresh%20look%22%20kahn&pg=PA207#v=onepage&q=%22objects%20a%20fresh%20look%22%20kahn&f=false" target="_blank">http://books.google.com/books?id=oiAkSgoiz6EC&lpg=PA207&ots=ShwbQwMNp9&dq=%22objects%20a%20fresh%20look%22%20kahn&pg=PA207#v=onepage&q=%22objects%20a%20fresh%20look%22%20kahn&f=false</a>>). Of the Vulcaneers, Ken (cc'ed) may have also originated this technique; I don't remember. Ken, do you have the full paper online? Do you remember how we came to realize the significance of this pattern?</div>
<div><br></div><div>Joule had two levels of semantic description. At the lower kernel layer, Joule was a pure actors language with a single implicit mailbox per actor. At the higher layer, which was more convenient for both users and implementors, a Joule actor had multiple facets -- directly supporting the power we'd discovered in the Vulcan project, that Ken's paper explains so well. A Joule actor as a whole still processed only one event at a time, but could service multiple mailboxes, one for each of its facets. In this way, a Joule actor was a cheap unit of atomicity among multiple services being provided from common state. I would count this as the first foundational step away from the "active objects" view of actors that Tom mentioned. Joule coupled this with (at this higher layer) direct support for inner-vs-outer sends. </div>
<div><br></div><div>
[...] Doug Barnes first created Original-E, by shoehorning Joule-inspired
concurrency onto a Java base in an intense two week efforts driven by a
business panic, after a contractual dispute between Agorics (creator,
provider, and supporter of Joule, where I was) and Electric Communities
(using Joule to create a decentralized secure virtual reality, where Doug
Barnes was). I only joined E.C. a year or so later, in 1995, whereupon I
took over leadership of the Original-E effort.
The significance of that step cannot be underestimated. Prior to this, all
the Actors and concurrent logic work that I was aware of assumed that, to
get a language with a sensible concurrency control model (e.g., actors or
concurrent logic programming), you had to start with concurrency. After all,
the previous attempts we were aware of adding concurrency to a sequential
language base, including Multilisp btw, but including the earlier efforts of
geniuses like Dijkstra (semaphores) and Hoare (monitors), all ended up
making the shared state concurrency mistake, i.e., shared memory
multithreading with fine grained locking. For the Vulcaneers, this view had
been reinforced at PARC, as the other concurrency crowd there was developing
Cedar, an outgrowth of Mesa, which proceeded to inspire the Modula-Ns, where
very smart people made this mistake everywhere. (Hoare's CSP and
ccam avoided this mistake, but at such a severe loss of expressiveness that
we did not take it seriously.)
Looking at the results of Doug Barnes' two week effort, it was clear that
there was never any necessary conflict all along, but none of us had been
able to see it. The Joule concurrency constructs, grafted onto a sequential
Java base, did not push that base towards shared state concurrency. However,
even by the time I arrived at E.C., the Joule-like concurrency that Doug
added was not quarantined from Java's shared state concurrency, leaving a
mess. (I would argue that Scala today makes the same mistake.)
At E.C., Danfuzz Bornstein and I brought vats to Original-E, finally fully
separating Original-E's Joule-like concurrency from the hazards of Java's
shared state concurrency. In some ways the Original-E vat was based on the
Joule "tank", serving as a unit of preemptive termination and transparent
distribution. But this didn't help regarding concurrency models, as a Joule
tank, like an Actors worker, was still pervasively concurrent internally.
Instead, I realized that an Original-E vat was, in this sense, like a single
big highly-multi-faceted single Joule actor, where each locally exported
object acts as a distinct facet of the vat. In this context, Joule's inner
send became conventional LIFO immediate call-return, which any object within
a vat could only immediate-call other objects within the same vat. Whereas
anyone could do an eventual send to a facet of a vat, i.e., any object
within a vat they had a reference to, which would only queue up on the end
of the queue. The two-ended dequeue nature of Original-E's stack + pending
deliver queue is in this sense a direct reflection of the inner-send fix
that Dean contributed to that first Vulcan paper.
[...] A straightforward interpretation of "coarse-grained actor" would have
multiple capabilities into the shared state of the "actor". The important
addition is that, in a vat, the set of capabilities available from outside
the vat to the state in the vat can change dynamically. Thus, I think of is
as a worthy alternative to fine-grained actors models.
Exactly. The hard part for me of getting from Joule to this repair ofmultiple capabilities into the shared state of the "actor". The important
addition is that, in a vat, the set of capabilities available from outside
the vat to the state in the vat can change dynamically. Thus, I think of is
as a worthy alternative to fine-grained actors models.
Original-E was to see a local heap of sequential objects as a large
multi-faceted actor, and to realize that exporting a previously unexported
object from within this local heap was like *dynamically* adding a facet to
a Joule actor, which was not possible in Joule. Once I took on this shift of
perspective, much of the rest followed naturally.
The mechanics of Original-E references was still problematic, as Joule's
multichannels did not co-exist with sequentiality all that smoothly,
especially regarding problem reporting. In 1998, when Chip Morningstar
(cc'ed) and I derived E from Original-E, I returned to many aspects of
Xanadu's promise system that Joule had left behind. Sometime in early 1998,
when I sketched the eight hand drawn pages scanned in at <
http://erights.org/e/semantics.html> all this came together into the
reference mechanics of modern E.
--
Cheers,
--MarkM
--0016e64084dee8687304a58990bd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable <div>[+kenneth.kahn, +danfuzz, +douglas (barnes), +ehud.shapiro, +carl, +chip]</div><div><br></div>On Sun, Jun 12, 2011 at 3:54 AM, Constantine Plotnikov <span dir="ltr"><<a href="mailto:***@gmail.com" target="_blank">***@gmail.com</a>></span> wrote:<br> <div class="gmail_quote"><div>[...]�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>It would be interesting to know how this idea of Vat comes to E. I'm also interested whether there are other Actor model implementations (that declare that they such) where asynchronous components could share single event loop.</div> </div></blockquote><div><br></div>On Sun, Jun 12, 2011 at 10:48 AM, Dean Tribble <span dir="ltr"><<a href="mailto:***@e-dean.com" target="_blank">***@e-dean.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
Agreed.�The larger islands of sequential programming in E were quite a benefit for many kinds of programming, and is probably the key insight in [the] E computational model. [...]</blockquote><div><br></div><div>Thanks. To explain how E arrived at this insight, a bit of history. The following is all based on my old flawed memories, so cc'ing various involved people for corrections and gap-filling. For those new to this thread, more context can be found starting at <<a href="http://www.eros-os.org/pipermail/e-lang/2011-June/013865.html" target="_blank">http://www.eros-os.org/pipermail/e-lang/2011-June/013865.html</a>>. To contribute to this thread, please first subscribe at <<a href="http://www.eros-os.org/mailman/listinfo/e-lang" target="_blank">http://www.eros-os.org/mailman/listinfo/e-lang</a>> or your messages will be silently rejected.</div> <div><br></div><div><br></div><div>Ehud Shapiro's 1983 paper "A subset of Concurrent Prolog and its Interpreter" began the field of concurrent logic programming. That same year, Shapiro (cc'ed) and Takeuchi's "Object-oriented programming in concurrent Prolog" showed how to encode actors as a pattern of concurrent logic programming, by reifying the "mailbox" as a stream of incoming messages, provided by convention as a first argument to a goal. In 1987, Ken Kahn, Dean Tribble, Danny Bobrow, and myself formed the Vulcan project at PARC, initially to provide sugar to more directly express actors/objects on top of this concurrent logic programming base.</div> <div><br></div><div>Dean diagnosed and fixed a flaw in an early draft of "Vulcan: Logical Concurrent Objects", and in so doing invented the inner-vs-outer send technique which would later show up in Joule and become so important to our E story below. An outer send would append onto the tail of a stream of messages, adding a new message to be serviced after all previously queued messages. An inner send, it you had the capabilities needed to express it, would prepend a message onto the head of the stream of messages, to be servived ahead of all previously queued messages.</div> <div><br></div><div>Vijay Saraswat (hi Vijay -- it's good to see you here!) joined the Vulcan project soon afterwards. We never really made much use of our sugar, finding it didn't add much convenience and hid too much of the underlying power. And a good thing too. The sugar would have baked in the one-mailbox-per-actor assumption. By programming more directly on the base, we came to realize the power of having a single actor (or concurrent logic programming perpetual process) serve multiple mailboxes. This power is explained well in Ken Kahn's "Objects: A Fresh Look" (the crucial text seems to be in the pages missing between p217 and p220 in <<a href="http://books.google.com/books?id=oiAkSgoiz6EC&lpg=PA207&ots=ShwbQwMNp9&dq=%22objects%20a%20fresh%20look%22%20kahn&pg=PA207#v=onepage&q=%22objects%20a%20fresh%20look%22%20kahn&f=false" target="_blank">http://books.google.com/books?id=oiAkSgoiz6EC&lpg=PA207&ots=ShwbQwMNp9&dq=%22objects%20a%20fresh%20look%22%20kahn&pg=PA207#v=onepage&q=%22objects%20a%20fresh%20look%22%20kahn&f=false</a>>). Of the Vulcaneers, Ken (cc'ed) may have also originated this technique; I don't remember. Ken, do you have the full paper online? Do you remember how we came to realize the significance of this pattern?</div>
<div><br></div><div>Joule had two levels of semantic description. At the lower kernel layer, Joule was a pure actors language with a single implicit mailbox per actor. At the higher layer, which was more convenient for both users and implementors, a Joule actor had multiple facets -- directly supporting the power we'd discovered in the Vulcan project, that Ken's paper explains so well. A Joule actor as a whole still processed only one event at a time, but could service multiple mailboxes, one for each of its facets. In this way, a Joule actor was a cheap unit of atomicity among multiple services being provided from common state. I would count this as the first foundational step away from the "active objects" view of actors that Tom mentioned. Joule coupled this with (at this higher layer) direct support for inner-vs-outer sends. </div>
<div><br></div><div>