<!-- 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>