<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: atomic functions -->
<!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> -->
<!--X-Date: Sat, 5 May 1998 09:53:38 -0700 -->
<!--X-Message-Id: 199805052322.QAA01590#under,engr.sgi.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199804300159.DAA16625#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="msg00403.html">Previous</a>
| <a href="msg00405.html">Next</a>
]
Thread:
[ <a href="msg00612.html">Previous</a>
| <a href="msg00254.html">Next</a>
]
Index:
[ <A HREF="author.html#00404">Author</A>
| <A HREF="#00404">Date</A>
| <A HREF="thread.html#00404">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>: Tue, 05 May 1998 16:21:59 -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 Thu, 30 Apr 1998 03:59:20 +0200 (MET DST)
Felix A Croes<felix#xs1,simplex.nl> wrote:
> Having recently completed the implementation of the generic parsing
> utility that I posted about earlier, I am now preparing to convert
> my server to the lockless multithreading paradigm put forward on
> this list by J.C. Lawrence.
<bow>
Note: I haven't had a chance to follow the subsequent posts in this
thread in great detail. Apologies for any re-hashing.
> It has occurred to me that the commit-or-fail idea can be applied to
> parts of threads as well as entire threads, leading to the following
> concept of "atomic functions":
> An atomic function is a function that succeeds or fails as a
> whole. Any runtime error that is not caught within the function
> will lead to the entire function call, with all its effects and
> side-effects, being undone.
> Atomic functions would be used to enforce consistency -- just like a
> thread either fails or succeeds without leaving the mud in an
> inconsistent, half-completed state. Of course, every function
> called at the beginning of a thread is effectively called
> atomically, so code that depends on atomic functions can be replaced
> by code that depends on (atomic) threads. The advantage of atomic
> functions would be to place the function call within the wider
> thread context, which would be similar to imposing an execution
> order on threads. Also, calls to atomic functions could be nested.
Hurm. I'm not entirely sure I understand. Would this be a correct
re-phrasing?
An atomic function is a member of a special class of functions which
may be called from an executing event, but whose pass/fail result are
reported back to the caller as vs re-entering the C&C mechanism.
Note however that the *ONLY* possible use for such a function is to be
able to call it from an executing event, have it FAIL, and continue
execution of the event despite the failure. Why is this is only
possible use? Because if the function succeeds (the only other
possible return state of a function at this level), then there is no
effective difference between the execution pattern of such an "atomic
function" and any other form. It is only in the FAIL state that the
execution pattern is different.
Delving futher into the FAIL state semantics, if the caller is to also
FAIL because of the atomic function's failure, then the only gain from
the atomic function overhead is is that it may get earlier
notification of its impedending C&C failure via the atomic function
than it would have otherwise. This can be a notable performance
enhancement, but comes at significant cost in complexity of the
execution environment (which is now heirarchial as vs flat) and in
code. Additionally the benefit is only gained for callers of atomic
functions -- all other events suffer the penalty of the more complex
environment without any gain.
It is only when the calling function is intended to continue execution
despite the failure of the atomic function (at the C&C level), that
the execution pattern is different. However the functional gain here
I find (and found, I implemented somethign like this for a while)
to be illusionary. There just is no practical use for the feature.
Note: ColdC has a similar construct with their exception handling
model (Miro or Brandon can probably expand better than I there).
If an event fails C&C, it didn't happen. This seems obvious, but the
ramifications can take a while to sink it. Any event before C&C, or
which has failed C&C has NO existance. It is utterly virtual. What
does this mean? The fact of whether an event failed C&C is
meaningless. The event didn't exist, so therefore its return state
doesn't exist, so there is no semantic content to be found there.
If a tree didn't fall in the woods, did anyone not hear it?
Its a specious question for a more specious topic. You're asking for
the state of a non-existance. If your super-events are supposed to
make process decisions on the return codes of such non-existant
non-entites, just what are they deciding on? That ZZZ should happen
because YYY failed C&C due to Bubba's event C&C'ing first? Its just
bad logic.
--
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="00256" HREF="msg00256.html">[MUD-Dev] 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="msg00403.html">[MUD-Dev] Re: Motivations (was something else...)</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00405.html">[MUD-Dev] Re: regulating player-created objects</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00612.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00254.html">[MUD-Dev] Re: Mud-Client, and specifically, COOLMud and SFWhite</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00404"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00404"><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="00322" HREF="msg00322.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, 07:39 GMT
<UL>
<LI><strong><A NAME="00427" HREF="msg00427.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, 18:45 GMT
<UL>
<LI><strong><A NAME="00551" HREF="msg00551.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, 19:54 GMT
<UL>
<LI><strong><A NAME="00612" HREF="msg00612.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>, Fri 15 May 1998, 20:30 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00404" HREF="msg00404.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>, Tue 05 May 1998, 16:53 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00254" HREF="msg00254.html">[MUD-Dev] Re: Mud-Client, and specifically, COOLMud and SFWhite</A></strong>,
Jay Sax <a href="mailto:cimri1#gte,net">cimri1#gte,net</a>, Thu 30 Apr 1998, 01:41 GMT
<UL>
<LI><strong><A NAME="00257" HREF="msg00257.html">[MUD-Dev] Re: Mud-Client, and specifically, COOLMud and SFWhite</A></strong>,
Dan Root <a href="mailto:dar#thekeep,org">dar#thekeep,org</a>, Thu 30 Apr 1998, 02:34 GMT
</LI>
<LI><strong><A NAME="00306" HREF="msg00306.html">[MUD-Dev] Re: Mud-Client, and specifically, COOLMud and SFWhite</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 01 May 1998, 22:01 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00253" HREF="msg00253.html">[MUD-Dev] Supporting articles found for UOL play style</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 30 Apr 1998, 01:25 GMT
</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>
