On Feb 7, 2008, at 10:46 AM, Walter B. Ligon III wrote:
Sam,
I've been looking more closely at the state machine stuff in prep
for the stuff we're working on and I have some questions about the
mods you made wrt the the quicklist. I just want to be sure I
understand things right.
In the original implementation there was both a stack point and a
base point for the frame stack - that doesn't seem to be there any
more. Thus, whenever someone retrieves frame(0) they get the top of
stack - is that right? This is a bit of a problem, because when we
finish the child state machines we want to get to the original frame
during cleanup. Originally I envisioned this being usable both for
parallel state machines and nested state machines - but I'm not sure
we need that.
So one thing I could do is provide a pointer to the "Base" frame in
the SMCB, with a distinct function to retrieve that, or we could
modify the existing function to get frame(-1) - moving backwards on
the list (and assume the other end of the list is always the base)
or I could reimplement a more complex base pointer scheme.
I'm generally loath to increase the complexity if we don't need it.
The only reason to have a complete base pointer scheme would be to
have multiple nested instances where you need to get at a base
frame. This isn't needed for parallel state machines, because each
new state machine gets a new SMCB, but if we wanted to use this for
nested SMs, we'd need it.
Let me give an example. Suppose on the server I get a request, and
I want to implement that request with server-to-server methods.
Suppose then, in order to implement that function I want to run a
CLIENT state machine. In such a case I could push a client frame,
and then jump to s a client state machine (in theory). The trick
is, when I return I need to return to my original frame. This can
be done with the current system, if I know that the original frame
is directly above the previous. On the other hand, if I want to
create N parallel state machines, where N is determined by
information in a request (access from the current frame) when I
return from the state machines I don't know how many frames to pop
to get back to the original. I could create a specific pointer in
the SMCB, but this would mess up the nested case - because I can't
have a general nested case with a distinct pointer.
I didn't add a base pointer because I assumed that the machine pushing
all the nested state machines onto the frame stack would know how many
it pushed, and so therefore know how many to pop off. If you don't
want to keep track of that, you technically don't need a base pointer
-- its trivial to get the last entry out of the quicklist using the
prev pointer.
In the previous implementation, the stack frame was a static array of
8 frames. The reason I changed the frame stack from an array to a
list was to allow for more than 8 frames to be pushed -- I was using
the parallel state machine concept to push one nested machine for each
request to each server, so all I needed was more than 8 servers to run
into problems.
One way out is never do this with nested machines, but just create a
single "parallel" machine when I want to change frames.
I think the new code isn't all that much different from the way you
had it. I changed it because of the need for an unlimited number of
nested parallel state machines to be run, but expected its intended
use to be the same as before.
I hope this makes some sense.
The second problem is when we go to start the child frames, it
appears we start a new state machine for every frame in the list,
but at least one of those frames is the original frame, not a child
frame, so again, there is an issue. In original implementation we
only started SMs for frames above the base frame.
There's a specific check in the PINT_sm_start_child_frames code that
prevents this, and I'm using the pjmp to start nested state machines a
bunch without the parent being started as you describe. Can you send
me your code?
So, I think there are several ways to patch this up, but first I
want to be sure I'm not missing something - and second see if you
have any thoughts about whether certain scenarios are significant
such that we might need a more general nesting solution, versus a
simpler one.
I'm happy with the way things are at the moment, but maybe I'm the one
that's missing something. A good set of example state machines with
pjmps in place would probably help flush out all the potential
different uses that we both have.
-sam
Walt
--
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
