certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [certi-dev] Time advancement


From: Michael Raab
Subject: Re: [certi-dev] Time advancement
Date: Fri, 26 Nov 2010 13:01:14 +0100

Hi all,

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]