[Home] [Groups] - Message: [Prev in Group] [Next in Group]
6342: [MUD-Dev] Re: atomic functions
[Full Header] [Plain Text]
From: J C Lawrence <claw@under.engr.sgi.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Wed, 06 May 1998 16:02:02 -0700
References: [1]
Organization: Kanga.Nu
On Sun, 3 May 1998 19:22:52 -5
Jon A Lambert<jlsysinc@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@null.net
(Contractor) Internet: coder@ibm.net
---------(*) Internet: claw@under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
--
MUD-Dev: Advancing an unrealised future.