[MUD-Dev] Re: atomic functions

[Jon A. Lambert]

On  5 May 98 at 1:52, Felix A. Croes wrote:
> Jon A. Lambert <jlsysinc at 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 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.