On Jul 26, 2006, at 6:16 PM, Phil Carns wrote:
I think I'm getting voted down here, so I should probably just
shutup, but I don't think in practice we're going to have that
many child state machines that iterating through the list is at
all costly. I'm arguing for simpler mechanisms that fit in with
the job subsystem over something more fancy and possibly slightly
better performing.
Well, as far as the number of SMs goes, I would rather not risk
it. I still hope this is lightweight enough that we could
eventually use it in more places that would generate a lot of
children (like a re-architected sys-io implementation), though I
don't know if that will pan out in practice. I got bitten by a
similar assumption in the flow protocol- it used to track all of
its posted operations for testing rather than relying on someone to
notify it of completion. Admittedly the flow protocol is a more
obvious case and I should have known better, but at the time it
seemed reasonable :)
Hmm...I had been thinking about a flow implementation that used the
new concurrent state machine code...it sounds like that's a bad idea
because the testing and restarting would take too long to switch
between bmi and trove? We use the post/test model through pvfs2
though, so maybe I don't understand the issue.
I think that the way that you describe would work fine too, but
it would require a little more active work to check the status
of the array of child SMs and would require more code to keep
track of them.
Probably a bit more code yes, but it seems cleaner than keeping
around backpointers and checking for parents. Instead of driving
all state machines from one place, this event notification
scheme essentially replaces the last child state machine with the
parent, which seems like a bit of hack and harder to debug.
I think I'm lost now. What do you mean by replace? The states are
still isolated, jobs trigger the transitions, only one state action
gets executed at a time, there still may be a time gap between
completion of any given child and when the parent picks up
processing again, and there are still frames. I think both
approaches will look the same when running unless I missed
something. If Walt puts a longjmp() in there we can both hit him
over the head.
Heh. Don't give him ideas! ;-)
I was operating under the constraint that a state machine can only
post a job for itself. If I understand the current plan correctly,
using job_null in the child state machine to post a job for the
parent breaks that constraint, and so in some sense is a replace (the
job_null actually takes the parent smcb pointer). I think you're
probably right that its not a big difference either way, its just
cleaner in my head to only have state machines posting jobs for
themselves.
I think having a pointer to the parent actually improves
debugability (though I'm not sure this approach actually requires
it, all you really need is either a job descriptor or a pointer to
a counter). If I have a state machine that does something bad or
gets stuck it would be nice to be able to work backwards to find
out who invoked it, without having to search for it in a seperate
data structure.
I don't mean to keep struggling with this issue- I honestly think
that both approaches are pretty good, and if Walt implements it the
way I think he is going to, then 95% of developers won't notice the
difference anyway. At this point I am mostly hammering away to
make sure I am not missing a larger issue...
Walt probably got more discussion than he bargained for, but at the
least, lively discussion keeps me awake in the afternoon ;-).
-sam
-Phil
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
