[DGD] Dgd thread safety

[Josh Cassell]

Hi guys,
 
I have a couple of questions about the whole multi processor implementation that dgd is using. I don't have a multiprocessor machine to run dgd on yet, but in the slim chance that anyone ever uses any code I write with one (multi-proc comps are getitng closer and closer to standard I think)  I have been taking efforts to assure that anything I do is with the potential for threading conflicts in mind so that noone gets a migraine trying to fix things after the fact. 
 
I believe I understand thread local storage and there has been plenty of stuff I could find in the archives on it to fill in any blanks I might have drawn with regards to that. 
 
My first question has probably been answered somewhere as I seem to get vague recollections of bits and pieces of something I read, but here goes anwyays. How exactly does an object get to the state of being considered dirty? Does calling a method in an object dirty it? Or using function scope variables inside that object?  Or does it actually only check changes to the state of the object such as globals? If it is just globals, then is it only changes to those globals, or does any access of them result in the object getting flagged as a possible conflict? What about callouts inside those objects? Global variables being used in those callouts? And finally when an object has been flagged so, does any access to any of the objects on the callstack of the thread that made the change cause one of the threads to be rolled back? (ack sorry I realized my "first" question really turned out to be a shotgun of ten :| )
 
I guess I can deduce a few of these answers myself, or at least make myself look like a doofus head for having lousy deduction skills. It would seem to me that just accessing a function inside an object and using function scoped variables in those functions shouldn't cause a conflict, but I am not totally sure about accessing (not changing) global variables, which it seems like that could fall both ways depending on how its implemented. Then again the overhead to maintain track of these differences could be just way too much and the driver simply makes everything a thread touches that another one has also a rollback scenario. That would make any calls to a security daemon or math handler or something very expensive in terms of conflict though... Of course I am probably just totally wrong on all counts since Im such an amateur hack at this and thats why I am asking the experts.
 
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. 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? But well if it's possible to call a function in an object and have it be DGD thread safe, then I suppose a timer or command handler object could maintain an array of objects that are simply stubs to start 0 second callouts in themselves which call a gateway type function in said objects or even implements specific commands. Or would you gain nothing from this because the threads were not changing the starting object to begin with... ugh a little confused on this one still I guess. 
 
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 cause if you hurry up and end the thread after any change you make, you lessen the chance of any conflicts coming up...ugh but to me this brings up the question of how much overhead on the driver a zero second callout is. 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? (I realize that this is most likely very very implementation specific and dependent on how many users, what type of things your system and the users did the most, etc. but general guidance is all I seek. Even an idea of how much overhead a callout really is would be extremely helpful)
 
Sorry for the long post guys, but I really did dig for a lot of this stuff on my own and Im still stumbling a little blind. I sure appreciate your expertise.
 
Josh