<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: atomic functions -->
<!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> -->
<!--X-Date: Fri, 4 May 1998 13:20:09 -0700 -->
<!--X-Message-Id: 199805050247.VAA21587@dfw-ix1.ix.netcom.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199805042352.BAA05944#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="msg00382.html">Previous</a>
| <a href="msg00384.html">Next</a>
]
Thread:
[ <a href="msg00376.html">Previous</a>
| <a href="msg00388.html">Next</a>
]
Index:
[ <A HREF="author.html#00383">Author</A>
| <A HREF="#00383">Date</A>
| <A HREF="thread.html#00383">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>: Mon, 4 May 1998 22:51:18 -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 5 May 98 at 1:52, Felix A. Croes wrote:
> Jon A. Lambert <jlsysinc#ix,netcom.com> wrote:
> >[...]
> > 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.
>
> One S is thus revealed. What is Swizzle?
>
Once a writelock is obtained, a copy of the object is made and passed to
the requestor. If an event fails the pointers are "swizzled" back to
the original object (rollback). The terminology, for me, comes from
Texas persistent store (and is likely misappropriated).
[snipped long running atomic function]
> This works in C&C as well. An automatic solution would be to execute
> each event that has failed a certain number of times single-threadedly.
> Slightly different take: re-execute the offending event while postponing
> the completion of all other events that are also being executed.
I also implement limits for the retry of events and escalations in
priorities, which are by no accident similar to some of JC Lawrence's
ideas. :)
Additionally, I have optional event invocation parameters which can
ignore locking completely and set execution priorities. It's a very fast
way to gather fuzzy numbers for economic and ecological use. The ability
to set execution priorities is important for some system commands and
monitoring routines.
> > 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.
>
> Hmm... what is immediately obvious is that the worst-case behaviour
> of S&S is a total lock-up, while C&C is guaranteed to be always
> executing at least one event that will complete (if any events are
> being executed at all). This suggests that C&C will perform better
> if there are many conflicts. On the other hand, S&S offers the
> programmer more ways to handle those conflicts.
Oh no, deadlocks/lock-up are impossible because of spin-locking. That's
why I was illustrating the two extremes of standard locking mechanisms.
I don't see how any threads are guaranteed execution in C&C, unless they
are evntually escalated to single-threading as per your earlier
reference. How does atomic prevent another thread from accessing and
updating objects, unless you single thread/task it?
For both C&C and S&S failure rates increase proportionate to the number
of objects updated. In theory C&C should outperform S&S for large
numbers of events of short duration. For longer event durations C&C will
begin to re-schedule events more frequently than S&S. The question for
me is, will the overhead of rescheduling events be greater than S&S's
builtin wait or spin-time?
> I have a hard time fitting atomic sections into S&S, at all. It
> seems to be against the spirit of the system to do a rollback on
> failure if the programmer can perform explicit checks, thus
> avoiding the failure.
Quite rightly. Explicit atomic sections in my system are not necessary
since every event is implicitly atomic and would be redundant in my
model.
Note the checks are implicit not explicit. My example was to illustrate
that one could code an explicit check to avoid rollback for special
cases. The programmer cannot prevent LOCKFAIL failure of an event and
avoid it, thus rollback is critical. But they can override the default
action of rescheduling the event.
--
--/*\ 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="00376" HREF="msg00376.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="msg00382.html">[MUD-Dev] Re: There can be.. only ONE! (fwd)</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00384.html">[MUD-Dev] Re: FW: (Fwd) Bouncing mail</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00376.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00388.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00383"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00383"><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>
<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><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>
<LI><strong><A NAME="00388" HREF="msg00388.html">[MUD-Dev] Re: atomic functions</A></strong>,
Joel Dillon <a href="mailto:emily#cornholio,new.ox.ac.uk">emily#cornholio,new.ox.ac.uk</a>, Tue 05 May 1998, 07:17 GMT
<UL>
<LI><strong><A NAME="00557" HREF="msg00557.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, 21:32 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00386" HREF="msg00386.html">[MUD-Dev] Re: atomic functions</A></strong>,
Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Tue 05 May 1998, 06:25 GMT
<UL>
<LI><strong><A NAME="00464" HREF="msg00464.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>, Thu 07 May 1998, 22:58 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>
