Showing synchronous I/O on state diagram

[dhait]

Suppose I have a class which is in one of two states: "Waiting" and "Processing".  In the "Waiting" state, it is waiting for a synchronous I/O to complete (for example, it has called Windows "ReadFile" or socket library "Accept").  When the I/O completes, the call returns, and the object transitions to the "Processing" state, where it completes processing, and calls the I/O again, jumping back to the "Waiting" state.

How would I show this on a state diagram?  There doesn't seem to be an state transition corresponding to a "Return from Call".

[sl@sh]

Not sure what your problem is. From your description you shouldn't need the 'waiting' state at all. If you're calling an outside process and waiting for the return, your class should still show it as being in the processing state since it's calling of the outside process is just a part of it's own processing. NB. your class doesn't 'lose' it's state only because a transition leads outside the class.

If you *do* need to make a distinction between the class doing it's own processing or some outside processing (but I can't imagine why), then you would need to make a forked transition from the initial processing state to both the waiting state and the outside processing state. The 'return' transition from the outside state should join with a transition from your waiting state which then then leads back to the 'processing' state (meaning your 'waiting' state has no outside transition ingoing or out).

If you want to make a distinction between your class not having done the outside processing and having completed it, then you should have two 'processing' states instead of one.

Maybe what you need is none of the above, but then you should provide more detail.

HTH,
Stefan

[dhait]

Stefan - thanks for the reply.

The application envisioned is multi-threaded, with each thread sitting in a tight Read-Wait-Process loop.  The class is an active class, encapsulating the thread and the processing.  

The reason I want to distinguish between "Waiting" and "Processing" is that these are meaningful states to the user.  He would want to know how many threads are waiting for I/O at any given time, how many I/O's have taken place, etc.  Also, since each I/O call corresponds to a kernel call, resulting in a context switch, we may want to monitor this activity in case we decide to start scheduling these threads manually (instead of leaving it to the operating system).  So, it's important to document and implement the feature that the class can be in one of these two states. The intent is to show this detail so that an (possibly external) coder can look at that diagram and say, "OK, I see what he wants to do."

So, is the "forked transition" that you describe the best way to show this?

[sl@sh]

Technically, the fork and join might be 'a' solution, but I get the impression it would be a bad one:

From your description I still don't see the need to monitor your original classes' waiting/processing-states. As a matter of fact, I find it rather awkward the user needs to know and inquire about each and every thread/object that may call IO processes!

As I understand you what you need anyway is one class to monitor all IO calls. The IO-class(es) already have all the information needed, so shouldn't this be the place to model this feature? This way the user only needs to keep track of one class, and doesn't need to know about any other objects.

Since you mentioned calling system libraries you may not have the option to modify and use them for your monitoring purposes, but you can easily solve that by introducing a proxy object for your IO calls. Also create a IO-monitor object that just keeps track of whatever info you need. The proxy can just be a temporary object that gets instantiated on any IO call, reports to the monitor, then forwards the IO call to the actual target. Once the call returns, the proxy again reports to the monitor and returns to the caller. Since the 'reports' to the monitor object needn't be synchronized you can just fork a transition.

One other aspect I'd consider is whether this shouldn't be modeled as activity diagrams rather than state machines. When I'm talking state machine I am thinking of objects that don't really do a lot apart from changing their state. A window changing from custom size to minimized or maximized would be an example. What you are describing however is a system full of objects that don't do anything else but process - except for the synchronization bit. It's not like these objects are waiting for events to make them switch to any of a potentially large number of different states. Your states are basically defined by having completed a process (which, incidentally, is the way to convert activity diagrams into state machines)

It's not like there's a big difference, but activity diagrams might be better suited to visualize your concept.

Mind you, my experience with multi-threaded system modelling is limited to say the least. Maybe others have better suggestions on this issue.

[dhait]

From your description I still don't see the need to monitor your original classes' waiting/processing-states. As a matter of fact, I find it rather awkward the user needs to know and inquire about each and every thread/object that may call IO processes!

In fact, this is a quite common requirement for multi-user multithreaded server systems...For example, in any reasonable DBMS like SQLServer or Oracle, the system administrator can examine the different user processes and their states.

Since you mentioned calling system libraries you may not have the option to modify and use them for your monitoring purposes, but you can easily solve that by introducing a proxy object for your IO calls. Also create a IO-monitor object that just keeps track of whatever info you need. The proxy can just be a temporary object that gets instantiated on any IO call, reports to the monitor, then forwards the IO call to the actual target. Once the call returns, the proxy again reports to the monitor and returns to the caller. Since the 'reports' to the monitor object needn't be synchronized you can just fork a transition.

Well IMHO this sounds like a bit of overkill.  I am asking a modeling/diagramming question, you are responding with a design/implementation solution.  Instantiating an object on each I/O adds an incredible overhead to a high-performance application.  Keeping the objects around has its own problems.  Surely this is not necessary just to model a call to a synchronous "File Read" function?

One other aspect I'd consider is whether this shouldn't be modeled as activity diagrams rather than state machines. When I'm talking state machine I am thinking of objects that don't really do a lot apart from changing their state. A window changing from custom size to minimized or maximized would be an example. What you are describing however is a system full of objects that don't do anything else but process - except for the synchronization bit. It's not like these objects are waiting for events to make them switch to any of a potentially large number of different states. Your states are basically defined by having completed a process (which, incidentally, is the way to convert activity diagrams into state machines)

I simplified the situation to present the problem. In reality, each thread could have a number of I/O's outstanding (multiple ReadFiles, WriteFiles, Socket I/O), and it needs to keep track of its state at each point in time, WRT what has completed, what is outstanding, etc.
Also, each Thread object is self contained, and does not interact with the other threads at all, so a state diagram would seem to be more appropriate.

Mind you, my experience with multi-threaded system modelling is limited to say the least. Maybe others have better suggestions on this issue.

Hear, hear!

[sl@sh]

Sorry, looks like I got carried away a bit and suggested possible solutions a bit premature (and not even good ones, it seems). I'm not familiar with DBMS system design, so this is the point where I shut up

Since you do need the states maybe my first suggestion (the fork and join) wasn't that bad after all, but as I said, I have the feeling this is not the optimal solution - I just can't think of anything better at the moment.

[jeshaw2]

dhait;
Have you considered using a pair of substates; one for processing and one for waiting?  The transition action of the call moves you to the wait state; the receipt of data switches you back to processing.

just a thought...

[kenty]

Suppose I have a class which is in one of two states: "Waiting" and "Processing".  In the "Waiting" state, it is waiting for a synchronous I/O to complete (for example, it has called Windows "ReadFile" or socket library "Accept").  When the I/O completes, the call returns, and the object transitions to the "Processing" state, where it completes processing, and calls the I/O again, jumping back to the "Waiting" state.

How would I show this on a state diagram?  There doesn't seem to be an state transition corresponding to a "Return from Call".

jeshaw2 is right, have substates, ie "Ready", "Waiting" and "Processing".  The triggering event between "Waiting" and "Processing" are "Received Data" for when the system call returns and currently another triggering event called "Data Processed" which transitions from "Processing" to "Ready" when the processing is finished.  What you will find is that the "Data Processed" triggering event will probably have conditions (different triggering conditions, ie a boolean) and thus more substates are required (eg bad data, etc).  "Return from call" is simply modelled as a triggering event.