<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] C&C and Event Rescheduling -->
<!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> -->
<!--X-Date: from stimpy.globecomm.net [207.51.48.4] by in1.ibm.net id 869839892.54446-1 Fri Jul 25 14:11:32 1997 CUT -->
<!--X-Message-Id: 199707251411.JAA01418@dfw-ix2.ix.netcom.com -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev] C&C and Event Rescheduling</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:jlsysinc#ix,netcom.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="msg00239.html">Previous</a>
| <a href="msg00241.html">Next</a>
]
Thread:
[ <a href="msg00245.html">Previous</a>
| <a href="msg00243.html">Next</a>
]
Index:
[ <A HREF="author.html#00240">Author</A>
| <A HREF="#00240">Date</A>
| <A HREF="thread.html#00240">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] C&C and Event Rescheduling</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <<A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A>></LI>
<LI><em>Subject</em>: Re: [MUD-Dev] C&C and Event Rescheduling</LI>
<LI><em>From</em>: "Jon A. Lambert" <<A HREF="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</A>></LI>
<LI><em>Date</em>: Fri, 25 Jul 1997 10:11:54 -0400</LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
> From: clawrenc#cup,hp.com
> Subject: [MUD-Dev] C&C and Event Rescheduling
>
> In <<A HREF="msg00200.html">33CFCE6E.41C67EA6#iname,com</A>>, on 07/18/97
> at 01:22 PM, Shawn Halpenny <malachai#iname,com> said:
>
> >Yep, a slight change is necessary. Now (and again, roughly):
> >1. A client C requests object O from the database.
> >2. Add C to list of clients using O.
> >3. Return OC (a client-only copy of O) to C.
> >4. A client D (which may or may not be the same as C, but is on the
> > using-list for O) returns OC'.
> >5. If O has not changed since D's request for it (a different client
> > may have committed changes to O while D was processing), OC' is
> > atomically committed to the database, replacing O. D is removed
> > from O's using-list.
> >6. If O has changed since D's request for it, OC' is discarded and D
> > receives notification that OC' couldn't commit.
> >7. Clients in the using-list for O are asynchronously notified that
> > O has changed.
>
> Given that this basic pattern extend to all the objects which comprise
> a given event or transaction, this is identical in principle to my
> model.
>
This might be accomplished by separating methods into event methods
and regular methods. A regular method is never called by the event
manager since it isn't a logical transaction, while an event method
forms an application consistent transaction. Upon termination of an
event method an implicit commit is done. This should allow nested
transactions as a side effect of nested event method calls as long
as commits are delayed to the callers termination.
> There is reason behind all this madness: It reduces the number of
> data copies needed for transactions. By using this sort of layered
> scheme I manage to delay making a copy of the object until I
> absolutely need one (ie someone has attempted to modify the object).
On further thought, the amount of object copies doesn't bother me
to much as a performance issue. Many well-optimized locking DBs do
this as a matter of integrity. The wasted time and possible race
conditions in event rescheduling vs. wasted time waiting on "a lock"
and possible deadlocks do bother me. I can't really make an informed
guess as to which is better. Some heavy duty profiling is probably
in order.
>
> Re: #5. How do you determine that the object has changed during the
> execution of the event? I do this by always keeping an original copy
> of the object to compare to the copy current in the DB and then do a
> bit-wise comparison of the two objects. The original copy is the
> second copy made above for a modification.
>
> Aside: I'm actually getting *slightly* neater than this as the
> current plan encludes only making a copy of the object
> attribute/member which is changed, and then only comparing that at
> C&C.
The burdens of attribute detection are difficult. How does
one detect the difference between:
ObjectA method ()
{
x = ObjectB.attrX; // a direct reference
y = ObjectB.GetattrY(); // an indirect reference through accessor
// perhaps a derived attribute?
}
Another possibility is for the DB manager to push the requesting
events unique handle onto an interested parties list along with a
CRC. Upon an attempt to commit, you compare the stored event handle's
CRC to real objects CRC. Problem: How reliable is CRC-32/64?
Worst case: the 1 in 32 billion(?) burp causes an invalid pointer
reference followed by a big thump. On reboot and reload of DB
the invalid object reference is ideally gracefully groked.
Another issue: A performance judgment on CRC calculation vs. 2nd object
copy with memory/bitwise comparison.
>
> Concern:
>
> An event generated IO. How do you handle when it reschedules?
> Think about things like SAY, TELL, LOOK, etc for example cases.
>
You also mention somewhere below about how some objects undergoing
a state change will propagate/generate events (likely asynchronously).
I see these objects being very similar and/or handy with IO.
Maybe it's possible for either the DB manager or the VM to post
the object state change events to the event scheduler after the
point of a successful transaction commit.
This might require another special method/object language construct.
It would handle indirect state changes as long as the room container
is the primary propagator. And yes, even a temporary "neighborhood"
object could be born from the commit and die at the end of it's
state change method *boggle*
A global CHAT object could then spawn gobs of events during its
cycle through the world.
> Okay, 50 players in a room all moving west is unlikely. How about 50
> players in or near a room, some moving out the various doors, some
> coming back into the room having left, others picking up or dropping
> various objects (changes to the contents lists), Every single event is
> now compeating for the chance to get a single unmodified copy of that
> room when it C&C's.
>
> Now that I've cast doom and gloom. This need not be a huge problem.
> The fix is to change the manner in which you write
> events/transactions. The requirement is to split events into the
> smallest, fastest executing, logically consistant units you can. The
> idea is that by making the runtime of an individual event as short oas
> possible the chance of collision by other events is minimised.
> Further, by making the runtime short, the probability is that what a
> given event sequence contends with on its first step will not be
> contended for on its next step. eg:
>
You could go to a pure event model, where ALL method references are
considered object messages which are dispatched as events. I have
doubts whether any sort of application transactional integrity
could be easily achieved with this approach, unless there is a strong
in language mechanism in place. ala StartTransaction-EndTransaction.
This takes the implicit nature of persistence out of the language.
Blech...IMO implicity==simplicity for the potential mudlib coder.
[execution priority and starvation trimmed]
I need to look at this closer.
I agree with most of this conceptually. =)
JL
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00279" HREF="msg00279.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>
<ul compact><li><em>From:</em> clawrenc#cup,hp.com</li></ul>
<li><strong><A NAME="00243" HREF="msg00243.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>
<ul compact><li><em>From:</em> Shawn Halpenny <malachai#iname,com></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00239.html">Re: [MUD-Dev] Motivating people</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00241.html">Re: [MUD-Dev] Multi-threaded programming under Linux</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00245.html">Re: [MUD-Dev] OT: Multi-threaded programming under linux</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00243.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00240"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00240"><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>Re: [MUD-Dev] Stories?</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<LI><strong><A NAME="00251" HREF="msg00251.html">Re: [MUD-Dev] Stories?</A></strong>,
Matt Chatterley <a href="mailto:root#mpc,dyn.ml.org">root#mpc,dyn.ml.org</a>, Sun 27 Jul 1997, 21:33 GMT
</LI>
</ul>
<LI><strong><A NAME="00273" HREF="msg00273.html">Re: [MUD-Dev] Stories?</A></strong>,
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Wed 30 Jul 1997, 00:49 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00244" HREF="msg00244.html">Re: [MUD-Dev] Multi-threaded programming under Linux]</A></strong>,
Michael Hohensee <a href="mailto:michael#sparta,mainstream.net">michael#sparta,mainstream.net</a>, Sat 26 Jul 1997, 02:40 GMT
<UL>
<LI><strong><A NAME="00245" HREF="msg00245.html">Re: [MUD-Dev] OT: Multi-threaded programming under linux</A></strong>,
Orion Henry <a href="mailto:ohenry#sdcc10,ucsd.edu">ohenry#sdcc10,ucsd.edu</a>, Sat 26 Jul 1997, 06:19 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00240" HREF="msg00240.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Fri 25 Jul 1997, 21:11 GMT
<UL>
<LI><strong><A NAME="00243" HREF="msg00243.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>,
Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Sat 26 Jul 1997, 00:48 GMT
<UL>
<LI><strong><A NAME="00246" HREF="msg00246.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>,
Miroslav Silovic <a href="mailto:silovic#srce,hr">silovic#srce,hr</a>, Sun 27 Jul 1997, 00:42 GMT
<UL>
<LI><strong><A NAME="00274" HREF="msg00274.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>,
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Wed 30 Jul 1997, 01:10 GMT
<UL>
<LI><strong><A NAME="00289" HREF="msg00289.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>,
Miroslav Silovic <a href="mailto:silovic#petra,zesoi.fer.hr">silovic#petra,zesoi.fer.hr</a>, Wed 30 Jul 1997, 20:43 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>