|Suspending timing services? [message #1791918]
|Sat, 07 July 2018 00:41
| reza ahmadi
Registered: September 2016
In a setting I have two communicating capsules Client and Server.
Capsule Client has some timers. Capsule Server needs to do some computations before it can send messages to capsule Client. While these computations are happening in Server, timers are obviously advancing in Client. So, once the message is prepared by Server and sent, the message enables some transitions T0 in Client, and in case the next transition T1 in Client is enabled by a timer like timer1.timeout, and in case the time elapsed to complete the mentioned computations in Server are at least equal to the timer value of timer1, then the transition T1 is triggered right away.
Is it possible to freeze the timing services during the computations in the Server capsule and resume it after the computations?
I tried using timeAdjustStart and timeAdjustComplete with a delta of 0 as a "trick" to suspend the timing services on the Client during the computations on the Server, but it just freezes the whole executing thread; the running program stops.
As an alternative approach I calculate the elapsed time for computations on the Server and send it to Client, so Client can set the timers with that offset time, but this approach works if the timers are triggered using informIn only (not if we use e.g. informEvery).
Thank you very much for any comments.
[Updated on: Sat, 07 July 2018 00:46]
Report message to a moderator
|Re: Suspending timing services? [message #1792114 is a reply to message #1791918]
|Wed, 11 July 2018 19:29
| Ernesto Posse
Registered: March 2011
I don't really understand your scenario and the need to freeze time. But it is correct that the timeAdjust* functions are the functions that can be used to "freeze" time. Unfortunately I don't know much about them so I'm not entirely sure about their semantics.
Reading the RSA-RTE docs for the equivalent function doesn't clarify much. Since they are methods on a timer, you could think that they apply only to one timer, but given the description of what they do, I would expect that they adjust the "local" clock, i.e. the clock for the controller running the capsules. This means that if you freeze time for one capsule, it freezes for all capsules that run in that same controller. So if you really need to freeze time in one capsule and not another (which I don't understand) you could try running the two capsules in separate controllers.
Nevertheless, to me these methods are a bit contrary to the abstract semantics of UML-RT, and I would avoid them if possible, and stick to purely model-based solutions. It sounds like you thought of an alternative using "informIn" but you need "informEvery" instead. Well, the effect of "informEvery" can be emulated with informIn and a state with some self-transition and a timeout trigger: when you get the timeout you call informIn again.
Powered by FUDForum
. Page generated in 0.02488 seconds