<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Re: atomic functions --> <!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> --> <!--X-Date: Thu, 3 May 1998 09:50:29 -0700 --> <!--X-Message-Id: 199805032318.SAA22877@dfw-ix3.ix.netcom.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: 199805031743.TAA20450#xs1,simplex.nl --> <!--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: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="msg00344.html">Previous</a> | <a href="msg00338.html">Next</a> ] Thread: [ <a href="msg00339.html">Previous</a> | <a href="msg00446.html">Next</a> ] Index: [ <A HREF="author.html#00345">Author</A> | <A HREF="#00345">Date</A> | <A HREF="thread.html#00345">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>: "Jon A. Lambert" <<A HREF="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</A>></LI> <LI><em>Date</em>: Sun, 3 May 1998 19:22:52 -5</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 3 May 98 at 19:43, Felix A. Croes wrote: > Jon A. Lambert <jlsysinc#ix,netcom.com> wrote: > > On 3 May 98 at 1:23, Felix A. Croes wrote: [snip] > > > Hmm. That is one thing I mean to do differently: if the current > > > event fails to commit, then any events generated by it are unscheduled. > > > > Currently I have no way to do this. > > In your system, isn't it also necessary to check the state of successor > events? For example: event A schedules event B, and then fails. Event > B is started and succeeds. Event A is restarted, schedules event B > again, and succeeds. Event B is started and succeeds. Now event A has > completed once, but successor event B has completed twice, even though > B can only be scheduled by A. > > Also, doesn't this imply that when A schedules B, it cannot pass along > data to B? After all, that data has been prepared by an event that may > turn out not to have existed. > > This looks like a very chaotic system to me. What are the advantages > that make you prefer it? > Excellent questions. The implementation details of S&S vs. C&C come into play here. C&C would check for event failure at the termination or close of the event when all the object changes are being compared. OTOH S&S attempts to obtain locks or escalate locks on objects during the events execution. So failure is known prior to end of the event code. So if Event B is logically dependent on Event A's success, Event A should not issue Event B until such a point where it is guaranteed to complete. Perhaps an example would illustrate this better. A() { i = objX.property; // A read lock is issued on objX. // code fragment objX.property = j; // The read lock is escalated to a write lock. // more code frags. if (problem) throw USER_ERROR; // note this is a detected and // expected state problem. event B(); // If execution of A is here success of above // is guaranteed. // more code // Note if LOCK_FAIL is detected here Event // A is no longer guaranteed to commit. So // event B above is suspect if it is truly // dependent on A's success. catch { if (USER_ERROR) { event C(); } // Error caught if (LOCK_FAIL) { // By default on LOCK_FAIL, event A would be rescheduled // Code here could override that behavior // so even "event A(modified params);" is possible. } } } Of course this raises the ugly issue of deadlocks. For example, events A and B are currently executing. A() { objX.prop = expr; // writelock on X obtained --->objY.prop = expr; // currently waiting on writelock for Y } B() { objY.prop = expr; // write lock on Y obtained --->objX.prop = expr; // currently waiting on writelock for X } There a two extremes in implementing locking and a wide area of middle ground. 1) Wait for lock forever. 2) Fail immediately upon not getting lock. and 3) Spin-locking -- repeatably try to obtain locks for duration X, X tries, or many other shemes. So one of the events (A or B) will fail, release it's lock and be rescheduled in my model. Trivia note: My terminology "spin-lock" comes from IBM's MVS/ESA architecture. MVS uses spin-locking in its page locking scheme to implement shared memory. Another possible downside of both C&C and S&S: A() { for each object in(biglistX) { objX = biglistX.current(); objX.prop = expr; } } What are the odds of this ever completing? Perhaps slim to none? My solution: A() { for each object in(biglistX) { objX = biglistX.current(); event objX.Setprop(expr); // events are issued for each object // Event A would only requires readlock on biglistX } } J.C. Lawrence is pretty steadfast in that C&C will outperform locking and I am still skeptical. The only thing I can say with reasonable certainty is that event rescheduling will be more frequent in C&C than in S&S. And execution wait time will be longer in S&S than in C&C. How this falls out in average throughput time, I an less certain. -- --/*\ Jon A. Lambert - TychoMUD Internet:jlsysinc#ix,netcom.com /*\-- --/*\ Mud Server Developer's Page <<A HREF="http://www.netcom.com/~jlsysinc">http://www.netcom.com/~jlsysinc</A>> /*\-- --/*\ "Everything that deceives may be said to enchant" - Plato /*\-- -- MUD-Dev: Advancing an unrealised future. </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="00446" HREF="msg00446.html">[MUD-Dev] Re: atomic functions</A></strong> <ul compact><li><em>From:</em> J C Lawrence <claw#under,engr.sgi.com></li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="00339" HREF="msg00339.html">[MUD-Dev] Re: atomic functions</A></STRONG> <UL><LI><EM>From:</EM> "Felix A. Croes" <felix#xs1,simplex.nl></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00344.html">[MUD-Dev] Re: atomic functions</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00338.html">[MUD-Dev] Re: atomic functions</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00339.html">[MUD-Dev] Re: atomic functions</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00446.html">[MUD-Dev] Re: atomic functions</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00345"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00345"><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: atomic functions</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <ul compact> <ul compact> <LI><strong><A NAME="00457" HREF="msg00457.html">[MUD-Dev] Re: atomic functions</A></strong>, Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Thu 07 May 1998, 14:09 GMT <UL> <LI><strong><A NAME="00542" HREF="msg00542.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 13 May 1998, 18:23 GMT <UL> <LI><strong><A NAME="00560" HREF="msg00560.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, 22:14 GMT </LI> </UL> </LI> </UL> </LI> </ul> </ul> </ul> <LI><strong><A NAME="00339" HREF="msg00339.html">[MUD-Dev] Re: atomic functions</A></strong>, Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Sun 03 May 1998, 17:45 GMT <UL> <LI><strong><A NAME="00345" HREF="msg00345.html">[MUD-Dev] Re: atomic functions</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Sun 03 May 1998, 16:50 GMT <UL> <LI><strong><A NAME="00446" HREF="msg00446.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, 23:03 GMT </LI> </UL> </LI> <LI><strong><A NAME="00443" HREF="msg00443.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, 22:26 GMT </LI> </UL> </LI> <LI><strong><A NAME="00376" HREF="msg00376.html">[MUD-Dev] Re: atomic functions</A></strong>, Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Mon 04 May 1998, 17:25 GMT <UL> <LI><strong><A NAME="00383" HREF="msg00383.html">[MUD-Dev] Re: atomic functions</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Mon 04 May 1998, 20:20 GMT </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>