I think there's no problem with the
tick management. Sorry for all the confusion.
The problem was when RAV was delivered
during tick() to our observer federate, we produced a very nasty exception,
that was unfortunately catched by __tick_kernel(). This caused the library
to block.
Thanks for all your efforts & Best regards,
Michael
Dipl.-Inf. Michael Raab
Fraunhofer-Institut für Fabrikbetrieb und -automatisierung IFF
Virtuell Interaktives Training
Sandtorstr. 22, 39106 Magdeburg, Germany
Telefon +49 (0) 391/ 40 90 122
Telefax +49 (0) 391/ 40 90 115
address@hidden http://www.iff.fraunhofer.de
oder http://www.vdtc.de
Von:
Eric Noulard <address@hidden>
An:
CERTI development discussions
<address@hidden>
Datum:
11/21/2010 01:22 PM
Betreff:
Re: [certi-dev]
Time advancement
Gesendet von:
address@hidden
Hi,
The Uppaal model (see http://www.uppaal.org/)
should now reflect the state of the current time management code
(with some detail abstracted away).
The model itself can be found in:
certi/doc/CERTI-tickHandling.xml
I attach screenshot of automaton diagrams for libRTI/Federate and
corresponding RTIA.
Those models are 'template' which can be instantiated.
I'll try to do some model-checking with this in order to check for
potential deadlock
or other unexpected/unwanted properties.
I did add some more comments about time management in
both libRTI and RTIA source code files.
I think it's definitely better than before but like I said
the code in this part is not simple because
1) Federate and RTIA are different "asynchronous" process
and even if Federate believes it's "only calling tick()"
several
messages may be exchange behind the scene
2) RTIA **needs** somehow to be asynchronous w.r.t. Federate because
it should always be ready to receive message from RTIG
(potential callbacks originating in other federate)
3) The code was simpler than the current one, but it got more complicated
because of the introduction of the "timeout" version
of "tick" which
is handled asynchronously in one process (RTIA) and "look-like"
synchronously
in libRTI but not quite.
May be this part of the code needs re-thinking/design, however it works
for many
of us but Michael so, that we have to fix it but carefully...
Michael, would you be able to provide us with a strip-down autonomous
example which exhibit the problem?
I'll definitely help on this but I do not currently have enough free
time to take it down now.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org
[Anhang "libRTI-model-shot.png" gelöscht von Michael Raab/VDT/ILA]
[Anhang "RTIA-model-shot.png" gelöscht von Michael Raab/VDT/ILA]
--
CERTI-Devel mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/certi-devel