Home > On-Demand Archives > Q&A Sessions >

Live Q&A - Painless Multithreading: How to Verify RTOS Best Practices in Runtime

Dr. Johan Kraft - Watch Now - EOC 2021 - Duration: 20:29

Live Q&A with Dr. Johan Kraft for the talk titled Painless Multithreading: How to Verify RTOS Best Practices in Runtime
M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

Hammarbytp
Score: 0 | 3 years ago | 1 reply

Hi, thanks for the talk.
I think the differences between Mutexes and semaphores in terms of priority inheritance is not the same across OS's. Vxworks (I beleive) provide priority inheritance for both semaphores and mutexes. However you are right to point out the complexity of semaphores and a relatively simple concept can get the unwary into a lot of trouble. We have had situations where you have 3 tasks sharing 2 semaphores, we can get a situation sharing two semaphores from both higher priority task, but when it release the higher priority task semaphore it maintains its higher priority despite only blocking a medium priority task, so causing a un-necessary delay in the higher task. These are largely caused by little known subtleties and different implementations of semaphores. This is not helped by the fact atht a) developers tend to throw semaphores and mutexes in as a safety feature, even if they are not actually needed and b) often the semaphore is used within the OS function calls itself, so you are not aware that a semaphore is being called

In fact the trend has to been look at alternatives to semaphores for this very reason

JohanKraft
Score: 0 | 3 years ago | no reply

Yes, my presentation was a bit simplified in this regard. There are other options for implementing signals between tasks that have more clear meaning, like task notifications in FreeRTOS, or message queues.

JohanKraft
Score: 0 | 3 years ago | no reply

Hi Tommy. The recorder library we use for FreeRTOS (and soon also Zephyr) can be used for bare metal systems as well, although you need to add suitable instrumentation. This is facilitated by the new SDK, that will be included in Tracealyzer v4.5 (coming soon).
Interrupts can be traced by calling the recorder library from the ISR. The overhead is typically a few microseconds, but depend on the processor and compiler settings. This is not recommended to trace highly frequent or timing-critical ISRs (where microseconds matter) as the overhead might become a problem.

tommypro
Score: 0 | 3 years ago | no reply

Are there trace techniques for bare metal functions/tasks?
How is interrupt tracing handled, and what is the overhead for this?

JohanKraft
Score: 0 | 3 years ago | no reply

Hi Gary. Thanks! Zephyr support is in progress. We are working on a new Tracealyzer release, v4.5.0, where Zephyr will be supported. This should be out in a few weeks. Target-side support will most likely be included in the next Zephyr release (v2.6) and I'm presenting the solution at the Zephyr Developer Summit on June 9. See https://github.com/zephyrproject-rtos/zephyr/wiki/2021-Zephyr-Developer-Summit.

garyhubley
Score: 0 | 3 years ago | no reply

Thanks for a great talk Johan!

Out of curiosity, does tracealyzer support Zephyr RTOS as well. All the demos I have seen at the conference so far have used freeRTOS.

JohanKraft
Score: 0 | 3 years ago | no reply

Welcome to this presentation. I'm available here between 15-16 CET, and then in the live Q&A session. But you can also post questions here afterwards and I'll try to answer as soon as possible.

10:40:47	 From  Dave Nadler : Thanks for a great presentation! You didn't mention potential deadlock detection - Does Tracelyzer include detection of different-order mutex acquisition etc.?
10:43:48	 From  Keith J : Thanks Johan - One of the better explanations of priority inversion and inheritance I've seen.  Will help me explain it to others.  Thank you!
10:45:07	 From  Radu Pralea : Can we also analyze the RTOS implementation (calls)overhead (every platform is different)?
10:45:07	 From  Peter Sik : What can be a measure to help decide if using an RTOS is worth it compared to bare-metal?
10:45:44	 From  Michael Kirkhart : Not directly related, but are there static analysis tools which are RTOS aware and can flag potential deadlocks?
10:45:50	 From  Dave Nadler : Do you mean super-loop when you say bare metal?
10:45:56	 From  Peter Sik : Yes
10:46:12	 From  Gary : Does Tracealyzer support multi-core architectures like stm32h7?
10:46:18	 From  JackW : Is it possible to store Tracealyzer diagnostics in non-volatile memory on an air-gapped embedded device, to be extracted for analysis later?
10:46:45	 From  Gary : Is Tracealyzer RTOS agnostic? Can it be used with Zephyr? 
10:47:08	 From  Dave Comer : How does (or does it) Tracealyizer work with QP?
10:47:44	 From  Erwin : Thanks for the good overview presentation. As Tracealyzer or better the trace library is currently more or less Bound to FreeRTOS hooks, are there any plans to extend further or even provide a bare metal library! JAcob you ar too fast :-)
10:51:31	 From  TommyPro : Sorry, joining late, so this question may have been asked.  Are there trace techniques for bare metal functions/tasks?
10:52:45	 From  TommyPro : How is interrupt tracing handled, and what is the overhead for this?
10:53:37	 From  Dave Nadler : Follow-on to the air-gapped capture question: Can the complete trace stream be written to storage using a background task, for later analysis?
10:54:21	 From  Jorge Conti : Are there static analysis tools which are RTOS aware and can flag potential deadlocks?
10:57:15	 From  Dave Nadler : What different hardware connections are supported from target to host?
10:57:21	 From  Nathan Jones : QP is Miro Samek's framework
10:57:32	 From  Miro Samek : QP is a real-time embedded framework
10:57:39	 From  Michael Kirkhart : https://en.wikipedia.org/wiki/QP_(framework)
10:57:57	 From  Matjaz Finc : You showed an issue in the NASA Pathfinder - was it really running FreeRTOS or I misunderstood?
10:58:21	 From  Miro Samek : Pathfinder ran VxWorks
10:58:29	 From  Matjaz Finc : thanx
10:59:39	 From  Keith J : Thank you Johan!!!
10:59:54	 From  Miro Samek : QP works at a higher level of abstraction than a naked RTOS. QP has its own software tracing (called QS), which predates Tracelyzer by many years.
11:00:29	 From  JackW : Thank you!
11:00:39	 From  Dave Nadler : Thanks Johan!

OUR SPONSORS

OUR PARTNERS