Add a New Comment (Rich Markup)
Thank you for your changes! I stumbled over one more thing: it is possible that the delta value is greather than tm._tick_timeout, which would result in a negative tm._select_timeout value. I used the edits in line 107 as a fix: tm._select_timeout = std::max(0.0,tm._select_timeout); (file #49707)
I have implemented a patch for this issue which needs further tests and investigations: The dedicated branch is br_bug_56284 and commit is e03d8ba9... An extension to existing Interactive Federate for 1516 2010 have been implemented to test the timings of the evokeXXXCalbacks() calls.
As we have discussed, the same behavior exists in the service tick(min,max) in HLA 1.3. Unfortunately, JCERTI does not work with HLA 1516 and so Ptolemy (written in Java) must stick with HLA 1.3. The code in RTIamServices.hh says: /**
*/ Boolean tick(TickTime minimum, TickTime maximum) throw (SpecifiedSaveLabelDoesNotExist, ConcurrentAccessAttempted, RTIinternalError); The environement Ptolemy-HLA was commited yesterday replacing tick() and tick2() by tick((MAX_BLOCKING_TIME, 0). For the moment, MAX_BLOCKING_TIME=1s. All tests pass and a federation syncrhnozed with the computer clock (at 1s) works fine. Here the way Ptolemy is using tick(min,max): while (!(_federateAmbassador.timeAdvanceGrant)) { // Wait for a callback. This will return immediately if there // is already a callback pending. If there is no callback pending, it will // wait up to MAX_BLOCKING_TIME and then return even if there is // no callback. // NOTE: The second argument, which the API confusingly calls "max" // but is usually less than "min", appears to not be used in the C++ code. _rtia.tick(MAX_BLOCKING_TIME, 0); }
The HLA standard defines a series of services to control the handling of the received callbacks. Two services are provided to retrieve the callback from the RTI 1) evokeCallback(ApproxMinTimeSecond) which only process a single callback and if none is available it is waiting for the given amount of minimum time specified in the method call before returning. 2) evokeMultipleCallbacks(ApproxMinTimeSecond, ApproxMaxTimeSecond) which allow to process multiple callbacks, it (1) must wait for the amount of time specified in ApproxMinTimeSecond parameter before returning (even if there is already multiple callbacks available) and (2) if no call is available during the ApproxMinTimeSecond, it waits for the given amount of maximum time (ApproxMaxTimeSecond) specified in the method call before returning and if during this time a callback is available then it must return immediately. During testing with evokeCallback(), I have observed that the evokeMultipleCallbacks(ApproxMinTimeSecond, ApproxMaxTimeSecond) is not working according to the HLA standard (at least my understanding of it). The reason is that the evokeMultipleCallbacks(...) method is returning immediately if there is one or many available callback and it is not waiting for the ApproxMinTimeSecond timeout. During my investigations, I found out that this is currently an implementation issue as the ApproxMinTimeSecond timeout is defined as the timeout for the select(...) call within the RTIA process, which return when there is a socket descriptor ready. The tick machine state is complex to handle and I am looking for a proper way to fix this without to much changes. It needs more investigations...
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
Depends on the following items: None found
Items that depend on this one: None found
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 2 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.11