[MUD-Dev] Re: atomic functions

[Jon A. Lambert]

On  6 May 98, J C Lawrence wrote:
> On Sat, 2 May 1998 03:41:43 -5  Jon A Lambert<jlsysinc at 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 at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--

--
MUD-Dev: Advancing an unrealised future.