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

 
 

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

Submitted by:  JbCh <jb_ch>
Submitted on:  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:  JbCh <jb_ch>
Open/Closed:  Open Release:  GIT-master
Reproducibility:  Every Time Fixed Release:  Unknown

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-05-10 jb_ch StatusConfirmed => In Progress

    Back to the top


    Powered by Savane 3.5