Re: [certi-dev] NextEventRequestAvailable and LBTS - Possible deadlock?

[Pierre Siron]

Bonjour,
Hello,
I suppose that the lookahead values are 0.
I can reproduce this bad behavior with the interactive federate
of the HLATestSuite.
Sorry, that works with two TARA (the RTIA can send a NULL message,
export RTIA_TM=D to see it), but that does not work with two NERA
(no NULL message sent).

The solution is to implement a GVT algorithm ?

As previously discussed in the TARA and NERA task (#6898),
to do this (GVT) computation could be a task dedicated to
the RTIG process (a centralized GVT computation, not a
distributed algorithm, initiated every Delta t).

Until now, the RTIG process just forwards the NULL messages
to the RTIA of the constrained federates.
My idea :
- when a federate calls NERA, the RTIA sends a NULL' message,
- the RTIG does not forward a NULL' message but it computes
a GVT,
- if this GVT grows in presence of NULL', it sends standard NULL messages.

This could also solve the time creep problem.

Is this algorithm correct ?
I have a doubt with complicated loops.

Best regards,
bien cordialement,
Pierre




Le 06/07/2010 12:15, Ijperen, Jeroen van a écrit :
> Hello,
>
> Currently I am having some difficulties getting my time constrained federates to work 
> with Certi. Each federate uses "NextEventRequestAvailable" to advance their 
> time, but none receive a TimeAdvanceGrant...
>
> My federation starts as follows:
> 1. Federate A starts, joins and becomes time constrained and time regulating
> 2. Federate A does a NERA (NextEventRequestAvailable) for time 1.0
> 3. Federate A received a TAG (TimeAdvanceGrant) callback for time 1.0
> 4. Federate B starts, joins and becomes time constrained
> 5. Federate B does a NERA for time 1.0
> 6. Federate B received a TAG callback for time 1.0
> 7. Federate A does a NERA for time 2.0 and waits for a TAG...
> 8. Federate B does a NERA for time 2.0 and waits for a TAG...
>
> Internally I see that at point 7 Federate A compares its requested time (2.0) 
> to the LBTS, which is 1.0 (the time Federate B was granted at 6). Since its 
> request is higher than the LBTS it keeps waiting. At point 8 Federate B 
> compares its requested time (also 2.0) to the LBTS, which is 1.0 (the time 
> Federate A was granted at 3).
>
> At this point in time both Federates are deadlocked as far as NERA is concerned.
>
> Can you reproduce this sequence of events, and how can we fix this?
>
> > From what I understood from the standard, is that a NERA can get a TAG 
> response with a lower time than requested, at the moment it receives TSO messages 
> for that lower time. I do not see this behavior in CERTI... I think it is 
> required, so that the LBTS can be updated with the requested times, as long as no 
> TSO messages need to be delivered for earlier times.
>
> Kind regards,
>
> Jeroen v. IJperen
> TASK24
>
>