[DGD] Dgd thread safety

[Noah Gibbs]

--- Josh Cassell <jcassell at microsoft.com> wrote:
> Now I read in the mailing list about the Dworkin's 3 golden rules to all
> this, and one of them was not to start threads in the same base objects.

  I don't remember whether starting a callout from an object effectively
modifies that object.  It used to (pre-multiprocessor), I think, but I don't
think it does any more.  The primary reason for this rule is that you'd like to
modify mainly just the object that started the thread, which gives you nice
simple rules for figuring out what object modification should occur where. 
Obviously it's not literally that simple (for instance, moving a mobile from
one room to another will modify at least both rooms, and possibly the mobile -
what object should start *that* thread?), but it's a great guideline, and you
can mostly assume that if a few other threads are running, they'll be likely
not to happen to modify the same object you are.  Well, unless you only *have*
about two rooms, and then you're not nearly as worried about multiprocessor
performance :-)  Dworkin's rule scales excellently to very large cases, and
multiprocessor performance is usually irrelevant in small cases.

> Well
> this would seem to me to be an argument for stuff like heartbeat functions 
> to be contained in all objects seperately and against gateway objects?

  Yeah.  If you're gonna start callouts in all your objects separately to
modify heartbeat stuff (which is actually a pretty good setup under DGD),
there's no real reason for a gateway/heartbeat/timeD object.  You're better off
just having each object know how to start its own delayed callout, and doing it
for itself.

> I guess the one thing I have walked away from this subject with a crystal
> clear understanding is that for DGD thread safety, 0 second callouts are very
> good

  Yup.  Also, they solve some problems with very large numbers of objects and
swapping, which was the traditional reason to do exactly the same thing in
other cases - break larger tasks up into smaller tasks separated by 0-second
callouts.  This is good for swapping and for avoiding problems like the Kernel
deciding that you've gotten yourself into an infinite loop because you take so
long to return.

> ugh but to me this brings up
> the question of how much overhead on the driver a zero second callout is.

  Surprisingly little, unless you're doing something that will cause a delay
after the thread ends (such as compiling and upgrading objects - much of the
work there happens while none of your code is running, after you exit).  And in
that case that's just taking the same delay and distributing it differently. 
The main problem you'll find with 0-second callouts is that you need to make
sure everything is in a consistent state when you finish.  If you're
mid-modification, there can be problems if another unrelated thread runs
between your two.  In effect, each thread is an atomic operation, so be careful
that your atomic operations are safe.

> Where is a good place to draw the line where the benefits of multiple
> processing threads outweighs the overhead of a  ton of zero second callouts
> and vice versa?

  Have you considered running some nice basic timing tests?  You could use the
Kernel Lib or just plain vanilla DGD and that'd give you a good starting point.
 Then you could say, "and does this look about right for multiprocessor DGD as
well?"  Felix is the only one who could answer that, so he probably would. 
He's good about that kind of thing.

  For the timing test, you could do a for() loop with ten million ordinary
function calls, and time it against ten million zero-second callouts.  There
are many other fine ways to do it, but if you can't think of another, that's a
good one.  It'll tell you about how many times slower a zero-second callout is
than a function call.  And once you know how long it takes to do ten million of
them (or a million, or whatever), you've got a good idea of how many you can
afford to do per second when your MUD is at full capacity.





		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/