[MUD-Dev] Re: atomic functions

Felix A. Croes felix at xs1.simplex.nl
Tue May 5 01:52:40 CEST 1998


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?


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

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.


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

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.

Felix Croes

--
MUD-Dev: Advancing an unrealised future.



More information about the mud-dev-archive mailing list