| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I took a look at the state machines, etc. some more. Shimon states the problem well in that TransmitFrame does not run instantaneously, yet the state machine conventions could imply that the call to TransmitFrame requires no waiting for completion. Shimon, do you know of any other aspect in the state machine conventions that would indicate that a call to TransmitFrame requires waiting for completion of that routine? Clause 4 seems to imply that algorithms are executed very fast.
State machine conventions do not imply any "waiting" in a state. If you want to wait for something, you define a variable and wait for it before you take a transition to the next state. TransmitFrame does not return any variables that we can use, nor does our state machine wait for them --- we just go to the next state via UCT. That is exactly the problem: we may do another call for TransmitFrame before the previous one was completed. The algorithms in clause 4 are "executed very fast", but they do not assume that things are instantaneous. That is why they use different Pascal constructs, with one of them being a function. Unlike a procedure, a function stalls the execution of the in-line code until the function returns, so that you can rely on the work that was done in the function. This is what makes our MAC work in the first place, but it breaks our state machine in this case. Shimon.