[MUD-Dev] Re: atomic functions

[J C Lawrence]

On Wed, 13 May 1998 15:54:52 -5 
Jon A Lambert<jlsysinc at ix.netcom.com> wrote:

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

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

Another key difference is that S&S allows (nay, actively encourages)
the user/programmer to actively consider and manipulate the locking
schema, where-as C&C explicitly hides all that from the programmer,
and denies all access to any event success/failure data during
execution.

The choice at that level then is:

  You can have your code work with the system, attempting to be a
"good citizen" and taking advantage of the rules where applicable, or
you can have your code on a competitive footing with all the other
code on the system, and its up to you as a programmer to make your
code fleeter of processor and lighter of tread than all the rest to
ensure its rapid execution.

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

This would seem a possible even likely source of logical
inconsistencies.

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

<nod>  The problem I have with this is that I am all too familiar with 
the cases of unpredicted race conditions and error cases, especially
as code is maintained over time.  I explicitly wanted a system which
attempted to be proof against such by rabidly insisting on the logical 
correctness of its execution model.

In this particular case, correct code which spawns a seperate event
during its execution may be safe now, but later edits to unrelated but 
called code can remove that safety:

  foo()
  {
    event bar();
    baz();
  }

  baz()  
  {
    other.call ();
  }

This as originally implemented is safe.  However, later the code for
"other" is edited such that the call to other.call() *may* potentially
fail.  This opens the door to bar() being launched repetitively as the
foo() event gets rescheduled.  Note that this does not violate your
conventions, tho it may be trapped by your compiler model depending on
how you do it.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...

--
MUD-Dev: Advancing an unrealised future.