| Understanding of the timer implementation [message #1834954] |
Sun, 22 November 2020 05:16  |
 Sneha Sahu
Messages: 20
Registered: June 2018 |
Junior Member |
|
|
in the attached figure, -
1. timer resets to 10 as entry action for A.
2. before timeout, triggerA is active and due to t1, now state becomes B.
3. as an entry action of B, timer is again reset to 5.
4. now at B, t3 gets active before timeout and state goes to A.
Now, my question is, what happens to these unprocessed timer signals? since both A and B are using the same timer port, does the new resets overwrite the previous ones, or do they get queued up on top of each other?
Kindly explain the behaviour of the default timing protocol implementation.
|
|
|
| Re: Understanding of the timer implementation [message #1835047 is a reply to message #1834954] |
Mon, 23 November 2020 23:45  |
Ernesto Posse
Messages: 438
Registered: March 2011 |
Senior Member |
|
|
Interesting question.
Well, the exact behaviour will depend on whether the two timers are set on the same Timer port or different ports. I assume you are setting them on the same port.
They key to understand this is that timeout messages are in fact just like ordinary messages, so they are treated (almost) the same way as normal messages.
This implies, for example, that if a timeout is triggered (the timeout message arrives) and you are in a state that does have a transition which handles the timeout (the transition's trigger is on the relevant timer port), then the transition will be taken, and if the state does *not* have a transition to handle that timeout, then the timeout is discarded, but a message will be printed on stdout. What happens exactly can be customized by overriding a method called "unexpectedMessage" (with signature void unexpectedMessage(void)" in the capsule.
Now, I said that the timeout messages are "almost" like ordinary messages, but there is a key difference. A UML-RT model runs in one or more "controllers". Each controller runs in its own OS-thread, and manages one or more capsules. By default, all capsules are allocated to one default controller, but you can allocate them to different controllers, although that's another question.
Now, each controller keeps separate queues for "normal" messages and "timeout" messages. The timer queue is sorted by time (the timers with sooner deadline first). Note that this is unlike other languages and models of computation, such as the Actor model, which keeps one queue per "Actor", or other languages which keep one queue per port. .
The controller has a "main" loop where it processes all messages. At the beginning of each iteration of this loop, it goes through all "expired" timers from the timer queue and adds them to the "incoming queue" (the queue for normal messages). Then, it processes all messages on the incoming queue until there are no more. If there are no more such messages, it will wait (block) until either a new normal message arrives or the first timer in the timer queue is triggered. When this happens, the next iteration of the main loop begins (moving timers to the incoming queue, etc. ...)
So in your example, the timers don't disappear when you jump to a different state (because timers are in fact managed by the controller, not the capsule and certainly not the state). In other words, the timers will trigger regardless of what state they were set up on, and when they trigger, the behaviour will depend on whether the current state has a transition that can handle them or not.
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04217 seconds
] 
Search
Help
Register
Login
Home
