1997Q3/
<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD&#45;Dev]  C&#38;C and Event Rescheduling -->
<!--X-From-R13: pynjerapNphc.uc.pbz -->
<!--X-Date: Tue, 12 Aug 1997 00:19:39 +0000 -->
<!--X-Message-Id: 199708120018.RAA06304#xsvr3,cup.hp.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199708012349.BAA04053#petra,zesoi.fer.hr -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev]  C&amp;C and Event Rescheduling</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:clawrenc#cup,hp.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>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->

Date:&nbsp;
[&nbsp;<a href="msg00478.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00480.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Thread:&nbsp;
[&nbsp;<a href="msg00331.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00097.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Index:&nbsp;
[&nbsp;<A HREF="author.html#00479">Author</A>
&nbsp;|&nbsp;<A HREF="#00479">Date</A>
&nbsp;|&nbsp;<A HREF="thread.html#00479">Thread</A>
&nbsp;]

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev]  C&amp;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&amp;C and Event Rescheduling</LI>
<LI><em>From</em>: <A HREF="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</A></LI>
<LI><em>Date</em>: Mon, 11 Aug 97 16:58:22 -0700</LI>
<LI><em>Reply-to</em>: <A HREF="mailto:claw#null,net">claw#null,net</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
In &lt;<A HREF="msg00331.html">199708012349.BAA04053#petra,zesoi.fer.hr</A>&gt;, on 08/01/97 
   at 05:03 PM, Miroslav Silovic &lt;silovic#petra,zesoi.fer.hr&gt; said:

&gt;&gt; &gt;I consider this a good thing. Remember, you have change_parents
&gt;&gt; &gt;function in Cold. When you call it, it guarantees that the database
&gt;&gt; &gt;will be consistant after termination. 
&gt;&gt; 
&gt;&gt; FWLIW I have a similar call, but I don't guarantee consistancy. 
&gt;&gt; Instead I rebuild the inheritance tree when an outdated object is
&gt;&gt; detected.  This doesn't change the workload much -- it just spreads it
&gt;&gt; out over time.

&gt;No, the problem we deal with is this: Suppose you have a helpnode,
&gt;and some moron decides to reparent it to room. Now this is almost
&gt;surely and admin mistake, but this is what then happens: helpnode is
&gt;tracked by help indices, and rooms are tracked by their realms. Now
&gt;if you /only/ change the inheritance, you have a room in a help index
&gt;and a room without its realm. This, of course, is a Bad Thing,
&gt;because you have also broken the help index.

&gt;The idea, then, is to call destructor method that destroys the
&gt;helpnode part of the help node (indidentally removing it from its
&gt;index) and calls constructor that does the housecleaning needed to
&gt;add a consistant room.

&gt;Now do this to a helpnode with 2000 descendants. Each of them is a
&gt;helpnode and, well, needs to be cleared.

&gt;Of course, this is not very realistic example, but adding parents to
&gt;user object may well be very desirable, and if the parent require
&gt;some internal state (suppose you're adding combat stats object to
&gt;user), Cold will guarantee that the entire hierarchy is properly
&gt;initialized.

&gt;This has *huge* working set, but the alternative of /not/ doing it
&gt;caused incredible number of problems in the past (it's utterly
&gt;annoying to have, for example, invalid objects in the player
&gt;database).

I don't see the problem IF you have a fail safe method of determining
that an object's inheritance tree is outdated.  For me the procedure
is:

  Event X is executing.
    References Object A.
    Is A in X's working set?
      No --
      Is A's inheritance tree up to date?
        No -- rebuild inheritance tree.
        Yes -- continue.
      Yes -- continue.
    Add A to X's working set.
    Continue.

Then you never need concern yourself if an object is out of date, as
any access to an object guarantees that it is up to date.

&gt;&gt; &gt;Actually I intend to reschedule the tasks with random delays,
&gt;&gt; &gt;precisely because of this (I believe this solution is standard).
&gt;&gt; &gt;Deadlock is improbable, then, because sooner or later things will
&gt;&gt; &gt;schedule in the right order, with proper pause between each.
&gt;&gt; 
&gt;&gt; Random rescheduling is a standard approach, however I wouldn't label
&gt;&gt; it a solution.  You might like to do a simulation here.  I suspect
&gt;&gt; you'll be surprised by the results.  The problem of this approach is
&gt;&gt; that its incredibly sensitive to both the load and to range of the
&gt;&gt; random number generated.  
&gt;&gt; 
&gt;&gt; Specific case:  If the random generation varies by a value which is
&gt;&gt; generally far smaller than the specific contending events in question,
&gt;&gt; then they'll continue to contend for a long while.  There are other
&gt;&gt; nasty cases (a simulation should show you most of the nasty ones).  

&gt;I actually intended to double the random delay on each reschedule.
&gt;This should take care of most of the problems. But you're quite
&gt;right, this will take some experimenting. Mind you, we don't even
&gt;have OS-level threading in place (or even in progress) yet. :)

There's some definitional fall out here:

  Is this a 

    -- select a random value, and then interatively double that
earlier value on each rescheduling?

or
    -- on each interation select a random rescheduling time from a
range whose total size doubles?

or

  -- on each interation select a random rescheduling time from a fixed
length range which is then appended to a time block whose length
doubles on each iteration?

I'm certain there are studies on this area, but I don't have time to
investigate.  My temptation however would be to have the rescheduling
time follow:

  Event X fails at time T.
  X will be rescheduled at a time S.
  S will be T + (N * Q) + rand(M * N)

  where:

    N is the number of times this event has been rescheduled.  

    Q is a fixed unit of time equal to 1/2 (this fraction requires
tuning) the runtime length of an average event.

    M is a fixed unit of time equal to the shortest common runtime of
an event.
    
It could also be profitable to make S:

  S will be T + rand(Q * N)
 
Testing would tell.

&gt;I'm actually interested on your opinion on doubling the delays each
&gt;time (well, doubling value 'x', then getting the delay as random(x),
&gt;to be more precise).

Ahh, you've answered the above question.  I *think* this would work
pretty well.  I'd really want to program up a little simulator that
ran say a test bed of 50 or 100 (P) simultaneous events which compeat
for a limited set of N resources (N == P, N&gt;P, N&lt;P, N&gt;&gt;P etc).  Let
the thing run for a few hours/day, vary the various weighting factors
and see what the results look like.  

It should take about a day or less to design, write, and debug,  Then
play with it for a week or so and see what sort of numbers and
performances you get out of it.

Note: You may also want to play with your random() algorithm, as well
as making the selection of seed on each call/thread be reset.  many
random() implementation area really NOT random for strict sequential
calls.

&gt;&gt; Unter originally took the replication model.  Latter design
&gt;&gt; discussions that I've heard of spoke of doing RPC until a threshhold
&gt;&gt; value (balance of local calls to remote calls from specific target) at
&gt;&gt; which point the object would be moved to the preferential server.

&gt;I like this, but i'd have to do some thinking to figure how to do it
&gt;(well, of course, I'll not be the only one to do the thinking).

It is what I'd like to do, but I have yet to come up with a really
decent design for it.  *ponders*  Something to chew on for those late
nights.

-- 
J C Lawrence                           Internet: claw#null,net
(Contractor)                           Internet: coder#ibm,net
---------------(*)               Internet: clawrenc#cup,hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...


</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="00331" HREF="msg00331.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></STRONG>
<UL><LI><EM>From:</EM> Miroslav Silovic &lt;silovic#petra,zesoi.fer.hr&gt;</LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00478.html">Re: [MUD-Dev]  Virtual Chemistry</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00480.html">Re: [MUD-Dev]  Virtual Chemistry</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00331.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00097.html">Re: Level abstractions / Game realism issues</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00479"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00479"><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>C&amp;C and Event Rescheduling</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00291" HREF="msg00291.html">C&amp;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, 22:35 GMT
</LI>
<LI><strong><A NAME="00312" HREF="msg00312.html">C&amp;C and Event Rescheduling</A></strong>, 
Miroslav Silovic <a href="mailto:silovic#mare,zesoi.fer.hr">silovic#mare,zesoi.fer.hr</a>, Thu 31 Jul 1997, 23:09 GMT
<UL>
<LI><strong><A NAME="00329" HREF="msg00329.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></strong>, 
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Sat 02 Aug 1997, 06:21 GMT
<UL>
<LI><strong><A NAME="00331" HREF="msg00331.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></strong>, 
Miroslav Silovic <a href="mailto:silovic#petra,zesoi.fer.hr">silovic#petra,zesoi.fer.hr</a>, Sat 02 Aug 1997, 06:56 GMT
<UL>
<LI><strong><A NAME="00479" HREF="msg00479.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></strong>, 
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Tue 12 Aug 1997, 00:19 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</ul>
</LI>
<LI><strong><A NAME="00097" HREF="msg00097.html">Re: Level abstractions / Game realism issues</A></strong>, 
Matt Chatterley <a href="mailto:root#mpc,dyn.ml.org">root#mpc,dyn.ml.org</a>, Fri 11 Jul 1997, 14:16 GMT
<LI><strong><A NAME="00096" HREF="msg00096.html">&gt;  Re: [MUD-Dev] Integrating PK</A></strong>, 
Matt Chatterley <a href="mailto:root#mpc,dyn.ml.org">root#mpc,dyn.ml.org</a>, Fri 11 Jul 1997, 13:26 GMT
<LI><strong><A NAME="00091" HREF="msg00091.html">Testing</A></strong>, 
coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Wed 09 Jul 1997, 12:55 GMT
<LI><strong><A NAME="00083" HREF="msg00083.html">What happened?</A></strong>, 
Michael Hohensee <a href="mailto:michael#sparta,mainstream.net">michael#sparta,mainstream.net</a>, Sun 06 Jul 1997, 21:58 GMT
</UL></BLOCKQUOTE>

</ul>
<hr>
<center>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
</center>
<hr>
</body>
</html>