<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: atomic functions -->
<!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> -->
<!--X-Date: Sat, 5 May 1998 10:53:05 -0700 -->
<!--X-Message-Id: 199805060021.RAA01811#under,engr.sgi.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 19980430161844.C346#sun104,humb.nt.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: atomic functions</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:claw#under,engr.sgi.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00405.html">Previous</a>
| <a href="msg00407.html">Next</a>
]
Thread:
[ <a href="msg00278.html">Previous</a>
| <a href="msg00322.html">Next</a>
]
Index:
[ <A HREF="author.html#00406">Author</A>
| <A HREF="#00406">Date</A>
| <A HREF="thread.html#00406">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: atomic functions</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: atomic functions </LI>
<LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>></LI>
<LI><em>Date</em>: Tue, 05 May 1998 17:21:27 -0700</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: "Petidomo List Agent -- Kanga.Nu version" <<A HREF="mailto:petidomo#kanga,nu">petidomo#kanga,nu</A>></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On Thu, 30 Apr 1998 16:18:44 -0400
Shawn Halpenny<malachai#iname,com> wrote:
> I'm not sure I understand how this alone will impose an execution
> order. If I have threads (I could even substitute "events")
> executing in parallel, normally whichever is able to C&C first,
> wins. Any order I impose on executing events depends on sequence
> numbers associated with the events themselves. Design details about
> the sequencing are still muddy, since I'm re-examining my approach.
This is an area that I'm still not happy with in my own design. The
specific area I'm not happy with is the handling of an event which has
failed C&C sufficiently to exhaust its rescheduling opportunities.
Details of the ugliness follow:
My basic model is simple:
An event may execute, and may define one or more events to be logged
if an when it itself succeeds at C&C.
This itself is fairly simple stuff. Each event of course only exists
as of when it passes C&C, and so can only logically cause things to
exist if it succeeds at C&C.
Complexity enters in two areas:
1) An event executes which logs two or more subsequent events with
the intention that some N event will finally be executed after all the
intervening events have successfully C&C'ed.
2) An event logs an event to follow it, and C&C's. That next event
similarly logs a follow-up event, C&C's and so on, daisy chain style.
(This is an extremely common construct). Eventually one of these
subsequent chained events is unable to C&C (exhausts its rescheduling
opportunities), and fails. The chain dies.
#1 may seem a bit complex. Diagrammed:
+--EventB--+
/ \
EventA EventD
\ /
+--EventC--+
Execution proceeds from left to right. EventB and EventC are executed
in parallel with their relative C&C order being inconsequential. More
complex scenarios are easily crafted, such as:
+--EventD--+
/ \
+--EventB----EventE----+--EventH--+---+--EventJ
/ \ / /
EventA +--EventF--+--EventG--+ /
\ / /
+--EventC----------+ /
\ /
+--EventI--+
ie EventJ executed only after EventH, EventG, and EventI have all
successfully C&C'ed, with each of those events having signficantly
different parentages. You can also get much nastier patterns where
the dependancies are on the prior C&C of events logged from utterly
seperate parentages.
Yes, this is nasty stuff. Happily I don't find it happens often.
Unhappily it always happens when I'm doing otherwise tricky stuff and
would *really* appreciate having a simple set of machinics to work
with.
My solution for the first (simple case) is that I allow the predicate
on an event to define that it can only run when all of its parent's
direct children (ie daisy-chain children) have C&C'ed. This is an
ugly solution. and I doin't like it one bit.
For the more complext cases I have an object heirarchy whose instances
act as semaphore objects. Its ugly. It effectively creates global
variables in the guise of first class objects, whose state is
protected by the C&C mechanism. Watchers and spoofs are then used to
effect synchronisation in the updates to the sempahore object states
such that the appropriate events are logged when the right time comes.
Ugly ugly ugly ugly. Wish I had something better.
Faint idea for a decent model which would allow solution of the entire
problem space in a reasonably elegant manner:
Expose the entire executing-events space as first class objects
which can be spoofed, watched etc.
For an event that fails C&C, no watches etc are triggered (after
all, it didn't exist), however the same watchers and spoofs are
installed on the next instance of that event when it comes back thru
the rescheduler.
Events can then install watchers on their own children, and then use
those watchers to effect coordination.
<shrug> Needs thought but could very well work.
#2 is the one that has a whole lot of my attention. The problem is
in handling the error condition. Sure, if the subject event is the
result of attempting to process a "go north" command, the final C&C
failure is not critical. The problem really occurs in the non-trivial
cases, especially when it is deep in an event daisy-chain.
Consider the case:
> l
You are in Panama.
> dig canal
You start digging the panama canal.
Now what actually happens is that the "dig canal" command starts a
very long event daisy chain. Each event digs a bit, and then logs a
new dig event for a little bit further in the future. Now lets say
that the 53rd such daisy-chained event ultimately fails its C&C (and
all attempted reschedules). What to do?
What if this event daisy chain didn't start from a user command, but
was generated by a mobile attempting its normal business of wandering
the land? If the event chain dies with that failed event the mobile
itself "dies" -- there are no more events to "animate" it.
My only solution has been to remove the possibility of an event
failing out fo the rescheduler. Every event must now eventually
succeed at C&C. The only variation is how hard the rescheduler tries
to get it to pass C&C early on in the reschedule process.
I can't see a logical course about this one. I actively suspect that
there isn't one, but am not prepared to invest the effort (now) to
prove it.
--
J C Lawrence Internet: claw#null,net
(Contractor) Internet: coder#ibm,net
---------(*) Internet: claw#under,engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
--
MUD-Dev: Advancing an unrealised future.
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00278" HREF="msg00278.html">[MUD-Dev] Re: atomic functions</A></STRONG>
<UL><LI><EM>From:</EM> Shawn Halpenny <malachai#iname,com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00405.html">[MUD-Dev] Re: regulating player-created objects</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00407.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00278.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00322.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00406"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00406"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: regulating player-created objects</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00456" HREF="msg00456.html">[MUD-Dev] Re: regulating player-created objects</A></strong>,
Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Thu 07 May 1998, 13:59 GMT
</LI>
<LI><strong><A NAME="00512" HREF="msg00512.html">[MUD-Dev] Re: regulating player-created objects</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Tue 12 May 1998, 01:25 GMT
</LI>
</ul>
</ul>
</ul>
</LI>
<LI><strong><A NAME="00256" HREF="msg00256.html">[MUD-Dev] atomic functions</A></strong>,
Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Thu 30 Apr 1998, 02:00 GMT
<UL>
<LI><strong><A NAME="00278" HREF="msg00278.html">[MUD-Dev] Re: atomic functions</A></strong>,
Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Thu 30 Apr 1998, 20:19 GMT
<UL>
<LI><strong><A NAME="00406" HREF="msg00406.html">[MUD-Dev] Re: atomic functions</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Tue 05 May 1998, 17:53 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00322" HREF="msg00322.html">[MUD-Dev] Re: atomic functions</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Sat 02 May 1998, 07:39 GMT
<UL>
<LI><strong><A NAME="00427" HREF="msg00427.html">[MUD-Dev] Re: atomic functions</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 06 May 1998, 18:45 GMT
<UL>
<LI><strong><A NAME="00551" HREF="msg00551.html">[MUD-Dev] Re: atomic functions</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 13 May 1998, 19:54 GMT
<UL>
<LI><strong><A NAME="00612" HREF="msg00612.html">[MUD-Dev] Re: atomic functions</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 15 May 1998, 20:30 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
