bugCERTI - Bugs: bug #56284, evokeMultipleCallbacks(..) HLA...

 
 

bug #56284: evokeMultipleCallbacks(..) HLA 2010 compliance issue

Submitter:  JbCh <jb_ch>
Submitted:  Tue 07 May 2019 09:00:57 PM UTC
   
 
Category:  CERTI Severity:  * 3 - Normal
Item Group:  HLA compliance error Status:  In Progress
Privacy:  Public Assigned to:  jb_ch
Open/Closed:  Open Release:  * GIT-master
Reproducibility:  Every Time Fixed Release:  * Unknown
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 26 Aug 2020 08:02:09 AM UTC, comment #3: 

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)

Moritz Gütlein <guetlein>
Fri 10 May 2019 03:38:57 PM UTC, comment #2: 

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.

JbCh <jb_ch>
Group administrator
Wed 08 May 2019 07:02:17 AM UTC, comment #1: 

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:
/**

  • Evoke multiple callbacks (HLA1.3).
  • Blocks up to "minimum" seconds until a callback delivery, then evokes
  • multiple callbacks until no callback is pending, or until "maximum"
  • duration is reached.
  • @param[in] minimum the minimum amount of time spent in the tick call.
  • @param[in] maximum the maximum amount of time spent in the tick call.
  • @return true if additional callbacks pending, false otherwise

 */
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); 
        }

janette cardoso <cardoso>
Group Member
Tue 07 May 2019 09:00:57 PM UTC, original submission:  

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...

JbCh <jb_ch>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #49707:  RTIA.cc added by guetlein (6KiB - text/x-c++src)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by guetlein (Updated the item)
  • -email is unavailable- added by cardoso (Posted a comment)
  • -email is unavailable- added by jb_ch (Submitted the item)
  •  

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-08-26 guetlein Attached File- Added RTIA.cc, #49707
    2019-05-10 jb_ch StatusConfirmed In Progress

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code