<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: atomic functions -->
<!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> -->
<!--X-Date: Sat, 2 May 1998 22:49:40 -0700 -->
<!--X-Message-Id: 199805030548.AAA07854@dfw-ix12.ix.netcom.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199805022323.BAA14736#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="msg00335.html">Previous</a>
| <a href="msg00340.html">Next</a>
]
Thread:
[ <a href="msg00335.html">Previous</a>
| <a href="msg00338.html">Next</a>
]
Index:
[ <A HREF="author.html#00336">Author</A>
| <A HREF="#00336">Date</A>
| <A HREF="thread.html#00336">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 01:52:04 -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 1:23, Felix A. Croes wrote:
> Jon A. Lambert <jlsysinc#ix,netcom.com> wrote:
I've combined both messages into one reply.
> My server is a rewrite from scratch of LPmud, so events can be
> generated in two different ways: a status change for a socket
> (connection available/input available/output done/connection lost)
> or with the infamous "call_out" function. I would like to rename
> the latter to something that makes more sense, but at this point
> I am bound to backward compatibility.
>
I'm not familiar with LPC, but my 'event method()' seems to be similar to
the LPC 'call_out()' function. Hrrm, so it's infamous is it?
> I mean to have both asynchronous event execution and data
> currency/integrity. The interesting part is that the same
> code can be used for both.
Yes. Exactly. Events that are asychronous have that property because
they have no data currency issues with each other.
> > My event method call() is
> > the explicit way of declaring that data currency is NOT important or
> > non-critical. Perhaps the semantic opposite of Felix's model?
>
> I don't understand this.
>
The backward compatibility issue with LPC makes explicit declaration
of atomic functions or code sections more critical to you. For me any
method entered via an event is implicitly atomic. And I must make calls
to execute methods that are no longer dependent on the currently
executing event's success explicit.
> > Thus an Event may be made up of many methods/functions, all of which must
> > succeed for the event to commit. Methods may schedule additional Events
> > and these events will be scheduled regardless of whether the generating
> > Event succeeds or not. So in many cases, Event calls will be obviously
> > be placed just before the successful return of the top-most method.
> > There is a caveat. A method/function which is called as an event
> > should ensure that it checks the state of the caller/callee for state
> > validity. Nothing comes for free. I have just shuffled the complexity
> > into another area of program design. I have a theory this might be
> > unavoidable. :(
>
> 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.
> Note that I mean to have atomic sections <in addition to> multithreading
> with commits and rollbacks (even though I may not implement them as
> rollbacks).
>
> Shawn has made me realize that there are two kinds of "atomicness".
> First, every (completed and committed) event can be said to be atomic in
> the sense that it does not overlap with other (completed and committed)
> events.
>
> Second, a section of code can be said to be atomic if it is executed
> either entirely or not at all. In my system, the two kinds are
> distinct. In Shawn's, they are identical. In a system that is
> multithreading in the same way but in which a runtime error does not
> cause the event to fail, only the first kind exists.
In my system only the first sort would exist. My events are
transactions. Either they are successful and commit or they fail and
rollback. Events execution order is unpredictable. They only way to
spawn new events within the mud language is by using the "event
method()", while a normal "method()" call does not. The driver will
of course generate events of it's own like data arriving on a
connection, startup, shutdown, sync points, and likely others I haven't
thought up yet.
For another take on atomic() see Cold's implementation at:
<<A HREF="http://ice.cold.org/bin/help?node=$help_func_atomic">http://ice.cold.org/bin/help?node=$help_func_atomic</A>>
--
--/*\ 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>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00335" HREF="msg00335.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="msg00335.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00340.html">[MUD-Dev] LIST: The "MUD-DEV" MUD Development mailing list</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00335.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00338.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00336"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00336"><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>
<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>
<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>
<LI><strong><A NAME="00338" HREF="msg00338.html">[MUD-Dev] Re: atomic functions</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sun 03 May 1998, 17:16 GMT
<UL>
<LI><strong><A NAME="00344" HREF="msg00344.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, 15:19 GMT
</LI>
<LI><strong><A NAME="00399" HREF="msg00399.html">[MUD-Dev] Re: atomic functions</A></strong>,
Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Tue 05 May 1998, 14:32 GMT
<UL>
<LI><strong><A NAME="00410" HREF="msg00410.html">[MUD-Dev] Re: atomic functions</A></strong>,
Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Tue 05 May 1998, 19:18 GMT
</LI>
</UL>
</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>
