[Pvfs2-developers] Re: State machine stuff

[Sam Lang]

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
>