I know that action starts to execute upon the entry, and the actions executes for do as long it's in the state.
but I think there's a lack of definition for entry, is it similar to do or the action executes upon entry to the state and it keeps executing even after leaving the state?
From UML 2.5 p. 307:
14.2.3.4.3 State entry, exit, and doActivity Behaviors
A State may have an associated entry Behavior. This Behavior, if defined, is executed whenever the State is entered through an external Transition. In addition, a State may also have an associated exit Behavior, which, if defined, is executed whenever the State is exited.
A State may also have an associated doActivity Behavior. This Behavior commences execution when the State is entered (but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be associated with the State, until:
it completes (in which case a completion event is generated) or
the State is exited, in which case execution of the doActivity Behavior is aborted.
The execution of a doActivity Behavior of a State is not affected by the firing of an internal Transition of that State.
Related
The UML standard states
terminate pseudostate
Entering a terminate pseudo state implies that
the execution of the state machine by means of its context object is
terminated. The state machine does not exit any states nor does it
perform any exit actions other than those associated with the
transition leading to the terminate pseudo state.
When should I use final and terminate pseudostate? For me terminate pseudostate can be replaced by a state with name "destroyed".
A lot of the explanations and examples out there are a bit cryptic, so let me see if I can put it in plainer English for you. A final state is where a process exits the state machine. A terminate pseudostate is one where the state machine shuts down.
One example might be a state machine for a cell phone call. You might have states such as find contact, initiate call, phone ringing, either go to voicemail or connect with contact, and then eventually to disconnect. In this case, the final state would be disconnect (or more correctly, disconnect would be the state that leads to the final state). Terminate pseudostates might be phone's battery dies, phone falls down garbage disposal, and so on.
I won't go so far as to say that a terminate pseudostate models an abnormal termination of a state machine, but that is what most practical applications of it use it for.
How to model Moore and Mealy machines with UML state diagrams? Besides, how to represent outputs in those diagrams? Through Actions?
UML state diagrams have the characteristics of both Mealy and Moore state machines.
To represent a pure Mealy machine, you use only actions on transitions:
stateA -- TRIGGER [guard] / action() --> stateB
To represent a pure Moore machine, you use only entry or exit actions to states, but you don't use actions on transitions:
stateA
entry/ actionA();
stateB
entry/ actionB();
When you use both actions on transitions and entry/exit actions in states, you have a mix of Mealy and Moore machines.
A statemachine can define behavior (p. 309 of the latest UML 2.5.1 specs):
14.2.3.4.3 State entry, exit, and doActivity Behaviors
A State may have an associated entry Behavior. This Behavior, if defined, is executed whenever the State is entered through an external Transition. In addition, a State may also have an associated exit Behavior, which, if defined, is executed whenever the State is exited.
A State may also have an associated doActivity Behavior. This Behavior commences execution when the State is entered (but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be associated with the State, until:
it completes (in which case a completion event is generated) or
the State is exited, in which case execution of the doActivity Behavior is aborted.
The execution of a doActivity Behavior of a State is not affected by the firing of an internal Transition of that State.
Read on at p. 320 about the notation of the latter.
How can I create a "terminating" state in UPPAAL? If there is no edge from a state the execution will stop with deadlock. If the state has a loop without any guard the execution has never stopped. What is the best way to stop the Simulator execution without deadlock (if there is)?
No there isn't any specific terminating state.
Check out the comments below the question for more details.
I did not understand the paradigm run-to-completion about state machine (14.2.3.9.1 UML 2.5 spec). At one point he says:
"Run-to-completion means that, in the absence of exceptions or asynchronous destruction of the context Classifier object or the StateMachine execution, a pending Event occurrence is dispatched only after the processing of the previous occurrence is completed and a stable state configuration has been reached. That is, an Event occurrence will never be dispatched while the StateMachine execution is busy processing the previous one"
and in another:
"IMPLEMENTATION NOTE. Run-to-completion is often mistakenly interpreted as implying that an executing StateMachine cannot be interrupted, which, of course [of course?? NDR] would lead to priority inversion issues in some time-sensitive systems. However, this is not the case; in a given implementation a thread executing a StateMachine step can be suspended, allowing higher-priority threads to run, and, once it is allocated processor time again by the underlying thread scheduler, it can safely resume its execution and complete its event processing"
So, is possible or not interrupt the state machine?? A new high priority event can interrupt the current event dispatch?
Thanks
Mauro
The implementation note refers to hard- or software implementation on a higher level. The completion is only valid for the context of the state machine. This machine may run in a global context which can allow to interrupt the processing of the state machine. But the state machine will not notice this interruption and from its own view it still continues processing. So, as mentioned, the only issue is that the state machines personal watch will not run continuously but with irregular jumps. In normal business processes this can be neglected, but when dealing with real-time-processing, you might get into trouble.
"an Event occurrence will never be dispatched while the StateMachine execution is busy processing the previous one" means that a StateMachine will not select the next Event from its queue until its run-to-completion step is completed. This does not prevent the state machine itself or other state machines from sending further events into its queue, while the run-to-completion step is running.
Moreover, a run-to-completion step might become suspended in the case of a synchronous Operation Call; the run-to-completion step will later be resumed when the operation call is completed (possibly returning a value).
I am trying to understand Posix threads. In the man page of pthread_cancel(), it is mentioned that "thread’s cancelability state, determined by pthread_setcancelstate(), can be enabled or disabled. If a thread has disabled cancellation, then a cancellation request remains queued until the thread enables cancellation.
But when I was reading about thread cancellation points on http://www.makelinux.net/alp/029, it is mentioned that if we set the cancel type as disabled (uncancellable), the cancellation requests are quietly ignored.
Can any one please let me know whether cancellation requests are getting queued or ignored if we set the cancellation type as DISABLED?
POSIX threads controls thread cancellation by a combination of two binaries variables:
cancellation STATE and cancellation TYPE. The associated functions are pthread_setcancelstate() and pthread_setcanceltype() accordingly.
When the STATE is set to disabled, the cancellation request is ignored.
It is not thrown out, it is suspended (or as you correctly wrote - "queued"), until the STATE is set back to enabled. Since the state is enabled, the OS starts the cancellation process according to the cancellation type. If you have a code that must be executed before a thread is cancelled (e.g. memory de-allocation etc.), you may set the thread cancellation state to disabled, before entering the code, and enable the cancellation exiting the code. The second question is how and when the thread is really stopped (cancelled). The the cancellation type answers this question. If the type is set to (not recommended) asynchronous, the cancellation may occur at the nearest instruction. If the type is set to the default deferred cancellation, the cancellation will occur at the next "cancellation point", a POSIX function that checks thread cancellation status and terminates the thread.