<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Re: atomic functions --> <!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> --> <!--X-Date: Wed, 6 May 1998 10:39:24 -0700 --> <!--X-Message-Id: 199805061738.KAA05108#under,engr.sgi.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: 199805011311.PAA02993#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:claw#under,engr.sgi.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="msg00419.html">Previous</a> | <a href="msg00421.html">Next</a> ] Thread: [ <a href="msg00331.html">Previous</a> | <a href="msg00333.html">Next</a> ] Index: [ <A HREF="author.html#00420">Author</A> | <A HREF="#00420">Date</A> | <A HREF="thread.html#00420">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>: J C Lawrence <<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>></LI> <LI><em>Date</em>: Wed, 06 May 1998 10:38:07 -0700</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 Fri, 1 May 1998 15:11:58 +0200 (MET DST) Felix A Croes<felix#xs1,simplex.nl> wrote: > What it actually does is impose an execution order on bits of > atomically executed code: > foo() > { > atomic { > /* code fragment 1 */ > } > atomic { > /* code fragment 2 */ > } > atomic { > /* code fragment 3 */ > } > } I suspect that you are confusing some logical equivalences. From an execution view point there are units which execute atomically. What the logical or language scope of those units are is really beside the point. They're merely atomic units, and it is from those units that the world progression is made. You are attempting to solve the problem of enforcing order of compleation of such atomic units thru blocking structures, and to add the concept of aggregate atomic actions via nesting. No? C&C odering really doesn't have anything to do with the C&C model, and is external to the atomicity requirements of the C&C model. Why? C&C defines the basic unit of existance: the state change. An individual state change is insular -- it has no relevance to other state changes. It is your __external__ process model which imposes its snes of order upon your state changes. Next up nested C&C's are a logical fallacy for similar reasons (there are some really good papers on this on the web if I could remember where), but a useful modelling tool. Nested C&C's offer the idea of a larger aggregate state change being composed of previously define and known insular state changes. The problem is that that model doesn't work at the logical level. The super-state change has to inherit the working sets and exit criteria of the nested state changes in order to validate its own C&C, and refuse the allow the nested state changes to commit until that time. If it did not it could fail C&C and attempt to rollback nested events which have already commited. Logical nightmare: EventA starts. Nested EventB starts. Nested EventB state-changes X. Nested EventB C&C's. EventB starts. EventA state-changes Y. EventB based on X's value, state-changes Y. EventB C&C's. EventA attempts to C&C, and fails due to Y being modified. EventA can't rollback the nested change to X as the change to Y is dependant on it. > Now, focusing on atomic code and abstracting from the rest, you can > map the sequence of code fragments to a sequence of atomic events. > Having events execute in parallel and compete for completion is done > to get the mud to run efficiently on multi-processor architectures. That is only one benefit. The parallel and competitive nature of the execution also adds sand-boxing benefits, protects the system against the run-time effects of rogue code, guarantees a minimal performance rate no matter load, etc. Essentially the server is now a multi-tasking OS with the "events" as its client processes. > But the atomic code property is also desirable from a software > design point of view, which is why I am trying to separate atomicity > and events. This doesn't work -- its logically flawed. An "event" is a state change. By their very nature and definition state changes are atomic in a C&C system. Attempting to seperate the concepts of atomicity and state changes is rather like attempting to seperate an automobile from a car. > It gets especially interesting when you nest atomic > code, allowing you to make code atomic on several abstraction > levels. Look at the *reason* for atomicity. In the C&C model atomicity exists as the definition of what happened. Nothing exists until it passes C&C. Now looking from a data-centric viewpoint, commits exist to mediate data access competition. You can push the point at which a state change is commited down to the very lowest __logical__ level (that logic being external to the data) -- you can't go any lower than that without problems in logical rollback. Or you can group multiple logical state-changes into a single commit -- you can group as much as you want there at the increased risk of C&C failure. So, there's a scale. The lower the granularity of your commit model, the larger the fraction of your processing time is going to be spent in C&C overhead. The larger the granularity of your commit model, the lesser the fraction spent on the C&C overhead, but the greater the chance of C&C collisions. You takes your picks, and suffers the results. -- J C Lawrence Internet: claw#null,net (Contractor) Internet: coder#ibm,net ---------(*) Internet: claw#under,engr.sgi.com ...Honourary Member of Clan McFud -- Teamer's Avenging Monolith... -- MUD-Dev: Advancing an unrealised future. </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="00296" HREF="msg00296.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="msg00419.html">[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00421.html">[MUD-Dev] Re: PK and my "Mobless MUD" idea</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00331.html">[MUD-Dev] Re: atomic functions</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00333.html">[MUD-Dev] Re: atomic functions</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00420"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00420"><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><A NAME="00297" HREF="msg00297.html">[MUD-Dev] Monthly FAQ Posting</A></strong>, Ling <a href="mailto:K.L.Lo-94#student,lboro.ac.uk">K.L.Lo-94#student,lboro.ac.uk</a>, Fri 01 May 1998, 17:11 GMT <LI><strong><A NAME="00296" HREF="msg00296.html">[MUD-Dev] Re: atomic functions</A></strong>, Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Fri 01 May 1998, 13:13 GMT <UL> <LI><strong><A NAME="00298" HREF="msg00298.html">[MUD-Dev] Re: atomic functions</A></strong>, Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Fri 01 May 1998, 17:27 GMT <UL> <LI><strong><A NAME="00331" HREF="msg00331.html">[MUD-Dev] Re: atomic functions</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Sat 02 May 1998, 18:16 GMT </LI> </UL> </LI> <LI><strong><A NAME="00420" HREF="msg00420.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, 17:39 GMT </LI> </UL> <UL> <li><Possible follow-up(s)><br> <LI><strong><A NAME="00333" HREF="msg00333.html">[MUD-Dev] Re: atomic functions</A></strong>, Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Sat 02 May 1998, 23:25 GMT </LI> <LI><strong><A NAME="00334" HREF="msg00334.html">[MUD-Dev] Re: atomic functions</A></strong>, Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Sat 02 May 1998, 23:26 GMT </LI> <LI><strong><A NAME="00335" HREF="msg00335.html">[MUD-Dev] Re: atomic functions</A></strong>, Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Sat 02 May 1998, 23:26 GMT <UL> <LI><strong><A NAME="00336" HREF="msg00336.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, 05:49 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>