[DGD] Dgd thread safety

[Josh Cassell]

Hey Thanks for your answers Noah.

The one question I still have from this is whether calling a function in
an object could lead to thread conflict if no state is changed in the
object itself, and if not then will using function scoped variables also
be possible? Right now I have a single object that handles all input
from a user and after cleaning it up gives it to different types of
command objects that call zero second callouts in themselves. The state
of the object is never modified and there are no global variables. Is
this ok or should this code be inherited by a user or some other cloned
object at the cost of larger classes and redundant code?

As for the testing, I have been busy building just such an automated
test bed type application on a stripped down version of the kernel lib
for exploring performance and timing stuff. Adding some stuff to help me
learn parse string as well. Looking forward to having tons of logs to
look at :D  *btw if you are reading this Erwin, thanks a bunch for the
website on parse string you sent me*

Btw sorry to go off topic, but why is there no built in support for
regular expressions in Dgd? Is this because the parse_string and sscanf
are plenty fast and could cover anything you could need?

Also using strings for bit manipulation is a bit strange feeling even
though it seems they are just arrays of chars and have no higher level
wrapping so should be ok... I hope. Looking throught the mailing list it
seems the experts have no problem doing this so it is with great shame I
ask just for peace of mind, Is there any problems performance wise with
doing it this way or any better way someone has of doing this? Is a byte
type not available because it is bad to use such things for dgd even
though bitwise operators seem available? Sorry for second guessing Im
pretty sure its ok, but I can't find it straight out confirmed anywher
:|

My next project is to go through the parse_string code in the dgd source
in an effort to figure out exactly what syntax of regular expressions
are supported. The code for which is rather daunting at first glance :D
*hint* really didn't want to ask a question that could be answered by
thorough research, but maybe someone could save me some time here if
they already have a good answer. Seems like a pretty bareboned regex
engine that supports just standard C chars and escaped strings, but I
would hate to not take advantage of something just cause I didn't know
about it.


Gosh for someone that planned on only asking one or two questions and
then keeping his mouth shut, it sure has been hard to hold back from
asking these questions that I haven't had a chance to ask anyone. Hope
its not too much and I am really sorry for what must be noob questions
for you guys.

Thanks a ton guys!
Josh

Ps 

The phantasmal mudlib has been a major tutor whenever I have had
questions about how things are done and how to do stuff. Also I doubt I
would have ever even started using Dgd without the phantasmal website as
an introduction, I was writing a mudserver in a hybrid c#/c++ half
.net/half native code at first and I spent 5% of my time coding and 95%
of my time banging my head against various hard objects in my office.
Once I started looking into it though I knew for sure dgd was something
I wanted to at least give a try and so far it has saved me so many
headaches hehe. 

So while I am very very grateful to everyone for all the work they have
shared that I have been able to learn with, I have to say special thanks
to you Noah for providing such noob friendly inspiration !

-----Original Message-----
From: dgd-admin at dworkin.nl [mailto:dgd-admin at dworkin.nl] On Behalf Of
Noah Gibbs
Sent: Tuesday, October 11, 2005 8:18 AM
To: dgd at dworkin.nl
Subject: Re: [DGD] Dgd thread safety

--- 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/
__________________________________________
http://mail.dworkin.nl/mailman/listinfo/dgd