[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