thanks for your effords. Have you changed
something in TICK management source code? I did a CVS update and now the
'error' stays the same (TICK request cannot be called recursively) but
the way to it is different..
I'm attaching a log file that may help
to identify the problem. It seems to me that there is TICK_REQUEST message
missing that should be sent from RTIA to libRTI when tick_state changes
from TICK_NEXT to TICK_RETURN.
I inserted some more logging info into
RTIA and a hand written comment into the respective line of the log file.
May be someone can have a short look.
Thanks & 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
error_tick.txt