[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