[MUD-Dev] Re: atomic functions
    J C Lawrence 
    claw at under.engr.sgi.com
       
    Wed May  6 16:02:02 CEST 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-archive
mailing list