[MUD-Dev] Re: atomic functions

J C Lawrence claw at under.engr.sgi.com
Wed May 6 16:02:02 New Zealand Standard Time 1998


On Sun, 3 May 1998 19:22:52 -5 
Jon A Lambert<jlsysinc at ix.netcom.com> wrote:

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

Quite.  My solution is almost identical to yours:

  Event {
    for each object in biglist {
      log event XXX.modify (object)
    }
  }

When the event executes it adds events for all the objects that need
to be processed to its exit criteria.  When it then C&C's those events 
are added to the Dispatchor and are processes as per normal from there.
    
> J.C. Lawrence is pretty steadfast in that C&C will outperform
> locking and I am still skeptical.  

Umm, no, I'm not.  I maintain that the two have different curves under
load and contention that are incredibly dependent on the exact loading
characteristics, and that I am satisfied with C&C's performance
characteristics.  C&C is not a godsend.  It has its own problems,
especially in recovery of process stack state, and in ordering.

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

Quite.  I expect it will be much more platform, process model, thread
model, implementation etc dependent as vs model dependent.

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



More information about the MUD-Dev mailing list