[MUD-Dev] Re: atomic functions

[Jon A. Lambert]

On  3 May 98 at 19:43, Felix A. Croes wrote:
> Jon A. Lambert <jlsysinc at 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 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.