<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] C&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&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>
[ <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="msg00478.html">Previous</a>
| <a href="msg00480.html">Next</a>
]
Thread:
[ <a href="msg00331.html">Previous</a>
| <a href="msg00097.html">Next</a>
]
Index:
[ <A HREF="author.html#00479">Author</A>
| <A HREF="#00479">Date</A>
| <A HREF="thread.html#00479">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>: <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 <<A HREF="msg00331.html">199708012349.BAA04053#petra,zesoi.fer.hr</A>>, on 08/01/97
at 05:03 PM, Miroslav Silovic <silovic#petra,zesoi.fer.hr> said:
>> >I consider this a good thing. Remember, you have change_parents
>> >function in Cold. When you call it, it guarantees that the database
>> >will be consistant after termination.
>>
>> FWLIW I have a similar call, but I don't guarantee consistancy.
>> Instead I rebuild the inheritance tree when an outdated object is
>> detected. This doesn't change the workload much -- it just spreads it
>> out over time.
>No, the problem we deal with is this: Suppose you have a helpnode,
>and some moron decides to reparent it to room. Now this is almost
>surely and admin mistake, but this is what then happens: helpnode is
>tracked by help indices, and rooms are tracked by their realms. Now
>if you /only/ change the inheritance, you have a room in a help index
>and a room without its realm. This, of course, is a Bad Thing,
>because you have also broken the help index.
>The idea, then, is to call destructor method that destroys the
>helpnode part of the help node (indidentally removing it from its
>index) and calls constructor that does the housecleaning needed to
>add a consistant room.
>Now do this to a helpnode with 2000 descendants. Each of them is a
>helpnode and, well, needs to be cleared.
>Of course, this is not very realistic example, but adding parents to
>user object may well be very desirable, and if the parent require
>some internal state (suppose you're adding combat stats object to
>user), Cold will guarantee that the entire hierarchy is properly
>initialized.
>This has *huge* working set, but the alternative of /not/ doing it
>caused incredible number of problems in the past (it's utterly
>annoying to have, for example, invalid objects in the player
>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.
>> >Actually I intend to reschedule the tasks with random delays,
>> >precisely because of this (I believe this solution is standard).
>> >Deadlock is improbable, then, because sooner or later things will
>> >schedule in the right order, with proper pause between each.
>>
>> Random rescheduling is a standard approach, however I wouldn't label
>> it a solution. You might like to do a simulation here. I suspect
>> you'll be surprised by the results. The problem of this approach is
>> that its incredibly sensitive to both the load and to range of the
>> random number generated.
>>
>> Specific case: If the random generation varies by a value which is
>> generally far smaller than the specific contending events in question,
>> then they'll continue to contend for a long while. There are other
>> nasty cases (a simulation should show you most of the nasty ones).
>I actually intended to double the random delay on each reschedule.
>This should take care of most of the problems. But you're quite
>right, this will take some experimenting. Mind you, we don't even
>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.
>I'm actually interested on your opinion on doubling the delays each
>time (well, doubling value 'x', then getting the delay as random(x),
>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>P, N<P, N>>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.
>> Unter originally took the replication model. Latter design
>> discussions that I've heard of spoke of doing RPC until a threshhold
>> value (balance of local calls to remote calls from specific target) at
>> which point the object would be moved to the preferential server.
>I like this, but i'd have to do some thinking to figure how to do it
>(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&C and Event Rescheduling</A></STRONG>
<UL><LI><EM>From:</EM> Miroslav Silovic <silovic#petra,zesoi.fer.hr></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&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&C and Event Rescheduling</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00291" HREF="msg00291.html">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, 22:35 GMT
</LI>
<LI><strong><A NAME="00312" HREF="msg00312.html">C&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&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&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&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">> 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>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>