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