<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: atomic functions -->
<!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> -->
<!--X-Date: Wed, 13 May 1998 12:54:27 -0700 -->
<!--X-Message-Id: 199805131953.OAA25486@dfw-ix16.ix.netcom.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: jlsysinc#ix,netcom.com -->
<!--X-Reference: 199805020738.CAA01505@dfw-ix2.ix.netcom.com -->
<!--X-Reference: 199805061844.LAA05603#under,engr.sgi.com -->
<!--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="msg00550.html">Previous</a>
| <a href="msg00552.html">Next</a>
]
Thread:
[ <a href="msg00427.html">Previous</a>
| <a href="msg00612.html">Next</a>
]
Index:
[ <A HREF="author.html#00551">Author</A>
| <A HREF="#00551">Date</A>
| <A HREF="thread.html#00551">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>: Wed, 13 May 1998 15:54: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 6 May 98, J C Lawrence wrote:
> On Sat, 2 May 1998 03:41:43 -5 Jon A Lambert<jlsysinc#ix,netcom.com> wrote:
>
Finally, I am back up and running, and at 400 mhz too. It's funny.
I can't seem to type or think any any faster at 400 mhz than at
166 mhz. <shrug> ;)
> > I'm adopting something I've dubbed S&S or Spin-Lock and Swizzle. In
> > essence a multithreaded locking system. But ignoring this
> > implementation detail, the language implementation is more relevant
> > here.
>
> ...deletia...
An explanation of Spin-Lock and Swizzle is probably in order:
S&S is an object locking mechanism as opposed to C&C which does not
lock. When an event begins execution and as it executes locks are
attempted against objects referenced by the MPL bytecode. Locks can
be of three types; read, write, and dontcare. Dontcare locks are a
special case and must be explicitly coded. Read and write locks are
implicit. The assumption of my model is that an event is the same
as a transaction, thus committing of changes occurs at the events
return. The fundamental difference from C&C is that when an event
returns, it is guaranteed to commit, and an event has knowledge of
it's success at a certain point and may act upon it.
> > foo()
> > {
> > /* code fragment 1 */
> > event bar(); /* bar is sceduled for execution as an atomic
> > function or independent event. Execution
> > foo() is not suspended but continues
> > */
> > bar(); /* executes bar() as a normal function bar is part of foo */
> > /* code fragment 3 */
> > }
> > bar()
> > {
> > /* code fragment 3 */
> > }
>
> > Either foo() or bar() may be events or normal functions. Whether
> > they are atomic events scheduled for independent execution is
> > dependent on how they are called. Commits are done on successful
> > event completion. Rollbacks are done on event failure.
It is important to note that the above code, or something of mine
resembling it, would receive warning messages from the compiler
indicating that events are issued prior to success.
Currently I do not investigate the nature of bar() in a single method
compile, but I do in a full object compile. So the warning message
may not be present in a full object compile, though it will always
occur in a single method compile.
> Problem:
>
> Foo() executes, and launches bar() as a seperate execution thread.
>
> Foo() then fails C&C (S&S?).
>
Foo() may have guaranteed it's success. It depends on whether the
requisite locks that bar() needs were already obtained within foo().
If, for instance, foo() and bar() are operations referencing the same
object then foo() is guaranteed success at the point it issues event
bar(). It's a poor example because I can't imagine why one would
invoke bar() as a method and as an event within foo(). But if you
replace event bar() with event xxx() then it makes some logical
sense as this fragment was just to illustrate the methods had two
ways they could be invoked, synchronously or asynchronously.
> What happens to the launched bar()?
>
It attempts to execute.
> Foo() reschedules, does it launch a new bar()?
>
Yes
> At some point data changes have to be committed. Given the rollback
> and reschedule aspect of the C&C approach, on what logical basis can
> you have nested commit structures or event fork()s _prior_ to commit?
>
I have always been of the opinion that application logic cannot be
known priori by the underlying mechanisms of the server. The
server may only provide the mechanisms, but it's still the task of
the MPL programmer to explicit code application logic. Basically both
C&C and S&S provide the underlying mechanisms for a concurrent and
persistent programming language. At some point these mechanisms MUST
appear either as implicit conventions or explicit language
constructs. It's a design decision of mine to implement the smallest
and simplest MPL I can and still keep the concurrent and
transactional nature intact. So underlying support for nested
transactions are beyond the scope of my language design. Each event
is a monolithic transaction and any desired nested transactional
dependencies are a matter of sequence in the coding of an event.
Implicit language conventions -
1) The start of an event is the start of an independent concurrent
transaction.
2) The return of an event is the end of the transaction and changes
are committed and locks are released.
3) Commits never fail.
4) Lock failure of an event can occur at any point during its
execution when a heretofore unreferenced object is referenced.
5) Lock failure cannot occur while referencing an object that has
already been referenced earlier in the event, unless such reference
escalates the nature of the lock (read to write).
6) The executing object is always read locked (e.g. in 'foo.bar()',
object foo is implicitly read locked, aka as 'this')
7) Lock failure causes all changes to be rolled back and all locks to
be released.
8) Failed events are rescheduled.
Explicit language conventions -
1) 'Event method()' invocation starts another independent concurrent
transaction.
2) For application logical consistency, dependent events must be
coded within the starting event where success is known. (aka
explicit transaction nesting)
3) Event failure may be caught through the use of exceptions and
implicit behavior may be overridden.
> Now if you mutate the C&C premise in some interesting fashion, (you
> never did really explain the basics of S&S), you can certainly do it
> -- but now you are talking about a whole different commit model.
> Essentially we are talking about the sematics and grammar of data
> state changes, and that grammar has to be logically demonstrable.
>
Hopefully the above adds a little more information on my model. No
It's not a mutation of C&C, probably the complement of C&C. Many of
the underlying mechanisms of object handling, caching and pointer
swizzling (via object copying) do resemble many of the C&C concepts
that you have disgorged on the list. :) <bow> As such, I should have
the ability to transform the higher mechanics into full-fledged C&C
if S&S proves to be a non-starter. As far as the grammar being
logically demonstratable, I am using many of the concepts that are
thoroughly enumerated in the many DB2 redbooks. For the purposes of
the list, I have only attempted to summarize the key features and
handle the potential problems as they are pointed out. <hehe>
--
--/*\ 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="00612" HREF="msg00612.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="00322" HREF="msg00322.html">[MUD-Dev] Re: atomic functions</A></STRONG>
<UL><LI><EM>From:</EM> "Jon A. Lambert" <jlsysinc#ix,netcom.com></LI></UL></LI>
<LI><STRONG><A NAME="00427" HREF="msg00427.html">[MUD-Dev] Re: atomic functions</A></STRONG>
<UL><LI><EM>From:</EM> J C Lawrence <claw#under,engr.sgi.com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00550.html">[MUD-Dev] Re: Some essays I've written lately</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00552.html">[MUD-Dev] Re: Mudschool</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00427.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00612.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00551"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00551"><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="00278" HREF="msg00278.html">[MUD-Dev] Re: atomic functions</A></strong>,
Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Thu 30 Apr 1998, 20:19 GMT
<UL>
<LI><strong><A NAME="00406" HREF="msg00406.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, 17:53 GMT
</LI>
</UL>
</LI>
<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>
</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>
