![]() |
Telelogic Rhapsody (steve huntington) | ![]() |
Topic Title: Open Space Discussion - OXF extensions, new functionality, debugging, hard real-time Topic Summary: Created On: 13-Jun-2006 20:01 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Discussion Topic: OXF extensions, new functionality, debugging, hard real-time
Leader Name: Martin Stockl Attendees: Nick Hancock Markus Beppler Christoph Schmidt Andreas Anderegg Stefan Moock Georg Heinrich Matthias Wufka Alexander Steinkogler Dennis Frölich Jens Laudien Richard de Klerk Matthias ReiBmann Holger Dethlefs Philip Zollinger Hartmut Schorrig Tim Shaw Dietmar Deinzer Jesper Gissel Christian Ewald Stefan Gerstenmeyer Herald Hewel Birgit Seitz Markus Gueller Session Notes: This is a discussion about the Rhapsody runtime execution framework (OXF), considering possible extensions, new functionality, debugging and working in ?hard? real time. How do I adapt OXF to my own event style? The best way to do this is by overriding virtual methods in OMEvent, and maybe also in OMThread. It is necessary to know a lot about how the OS handles events. Is it better to wrap OS events in OXF wrappers, or to wrap OXF events in OS wrappers? The consensus seems to be the former. How do I send an event from a signal interrupt routine to a specific thread? No clear answer. Certainly OS specific, and would require an extension. Rhapsody offers macros (GEN_ISR and CGEN_ISR) to achieve this for some OSes, but the user needs to verify whether the kind of MessageQueue implementation for his OS supports this. If not, then a customised active class needs to be developed, in order to support queuing events originated in an ISR. How do I manage the message queue for a given thread? The message queue can be handled in different ways: it may be fixed in size, or may grow from a fixed base. Action code which uses the GEN macro can check if an event was successfully placed on the message queue by looking at the return code: true if the event was put on the queue, false otherwise. There is also the option to use a blocking write to the event queue, although this is strongly discouraged since it can lead to deadlock unless handled very carefully. There is a runtime check to see if a reactive class is repeatedly queuing null events, but you should consider what happens if the queue size maxes out in this case. Be careful with state charts using only triggered operations. Null events on state chart initialisation are executed in the event thread, which is not intuitive when everything else operates synchronously. The Siemens solution to this was the introduction of an OMTriggered class, derived from OMReactive, but executing initial null transitions in the calling thread. A similar problem can occur with activity diagrams at the class level. Also, be careful with a triggered operation/event mixture in the same state chart. If a triggered operation is applied when an event is being processed in the event thread, it will be discarded. Therefore change the operation concurrency from asynchronous to guarded. If a transition is taking place, and the corresponding action causes a triggered operation to be invoked on the same state chart (this may happen either directly, or indirectly, for example by calling a method of another class which does a callback), then as described above the triggered operation will be discarded. This means that recursion isn?t really possible without special handling. One way of doing this is to provide your own queue on your class for outstanding triggered operations, so that each time a triggered operation completes, a check is made for further queued triggered operations, which can then be applied. Effectively, this serialises the triggered operations. It would be better if more generic support is provided for this by the framework, but there would have to be some limitations (what happens to the return code of a triggered operation?) How do you attach a timeout to an event? The event could be sent via the timer manager, so a special timer event is queued which must check to see if the associated event has been processed before being activated. Likewise, the event being supervised would need to cancel this special timer event. This would probably require an extension to the timer manager. There is also perhaps no real way of representing this in a state chart diagram. It is not sure that the UML defines this. If not, then some other way would need to be found. Animation may get confused by some changes e.g. deferred events, since it would consider that an event was consumed when it had just been queued. A general comment: bugs with provided solutions are not always confirmed as fixed in new releases of OXF. Enhancements tend not to be built into new releases very quickly, meaning that problems solved by customers have to be reapplied every time a new release comes out. This isn?t so much of an issue if OXF modifications are really customer-specific, but can be annoying if the problems are generic (which is often the case). Is there the possibility of altering the memory allocation strategy for the C framework? There is a need to realloc memory blocks when the current allocated blocks are all used up. This should be customisable at the active class level. Does memory ever get deallocated? It doesn?t appear so. This should be an enhancement request. Can the framework be told to use static memory allocation (e.g. for the message queue, task stack size, etc)? This probably requires customisation. It is noted that the framework cannot handle everything, for example deleting active threads. The documentation for the C framework implementation could be improved. It is possible to customise the existing thread implementation. It is possible to animate framework interactions by overriding and calling animation macros, although this is not provided as an option with the release. Please feel free to discuss further... |
|
![]() |
|
![]() |
|
Another point we have noticed is that, at least for the Linux OS, checking of return codes from OS system calls is patchy. I'm not sure how this squares with claims of safety-critical software. Any comments?
|
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.