of course I'm calling tick until the
appropriate grants arrive....
Attached to this mail you can find the
latest debug outputs of the federates before the deadlock occurs.
Apparently all of them are waiting for
a TAG.
Michael
Von:
Eric Noulard <address@hidden>
An:
CERTI development discussions
<address@hidden>
Datum:
15.06.2012 09:40
Betreff:
Re: [certi-dev]
CERTI deadlock
Gesendet von:
address@hidden
2012/6/15 Michael Raab <address@hidden>:
> Yes and No,
>
> for all our "active" federates, lookahead is 60 for the
complete simulation.
>
> For our "oberserver" federate the initialization/runtime
looks like this:
>
> - joinFederation
> - enableTimeRegulation( 0.0, 0.0 )
>
> // start all active federates...
>
> disableTimeRegulation()
>
> enableAsynchronousDelivery()
>
> while(true)
> {
> tick(0.1, 0.5)
>
> queryLTBS();
>
> // display current simulation time based
on LTBS
> }
>
> So for the startup phase lookahead of the observer is 0, but after
calling
> disableTimeRegulation() this shouldn't matter. Or am I wrong?
Should work, even if its strange to start with LK=0.
Note that you cannot expect your lookahead and/or time regulation to be
changed
until you (the federate) received the TimeRegulationEnabled.
The same is true for "enableAsynchronousDelivery".
so you should be ticking in order to get appropriate callback before entering
the endless loop.
That said, you said that the federation is blocked "at some point"
and not upon
startup so I can't imagine why a possibly faulty init could break
somewhere in the future....
fed_trace.txt