Embedded Control Systems Design/Asynchronous activities
This chapter explains how to exchange data between two activities that run in parallel, or to synchronize their executions.
interrupts and ISRs
[edit | edit source] |
A reader has identified this chapter as an undeveloped draft or outline. You can help to develop the work, or you can ask for assistance in the project room. |
Interrupts and ISRs (interrupt service routines) are the lowest level of asynchronous activity. All higher levels are built on this foundation. In some cases, the RTOS will handle all the low-level details for you.
We discuss interrupt and ISRs in more detail in other chapters --
- Embedded Control Systems Design/Operating_systems#Interrupts
- Embedded Control Systems Design/Real Time Operating systems#Interrupt servicing
- Embedded Control Systems Design/Design Patterns#Interrupts
threads sharing memory
[edit | edit source] |
A reader has identified this chapter as an undeveloped draft or outline. You can help to develop the work, or you can ask for assistance in the project room. |
Exchanging data between two threads sharing memory ...
medium level
interprocess communication
[edit | edit source] |
A reader has identified this chapter as an undeveloped draft or outline. You can help to develop the work, or you can ask for assistance in the project room. |
high level (= Interprocess Communication via asynchronous message passing between processes in separate protected memory areas).
computer to computer communication
[edit | edit source] |
A reader has identified this chapter as an undeveloped draft or outline. You can help to develop the work, or you can ask for assistance in the project room. |
RPC (remote procedure calls) ...
Software problems
[edit | edit source]When implementing the software code in a robot, there can be problems with synchronous threads. This section gives some bad programming examples in multithreaded systems. It is illustrated in C-code. They are concerned because it is a first step to understand problems which occur do to concurrent engineering on a higher level.
- When a program has a global variable and synchronous threads, thread 1 might be interrupted before the global variable is written and thread 2 might work on old data. This might still be acceptable, but the outcome of the program isn't what the programmer wants.
- When the global variable changes from a positive to a negative value between lines 4 and 8, none of the conditions are true. There's no function call and this can lead to problems.
- When two threads use the same resources, the principle of mutual exclusion can be used. This can be implemented with a global variable counter. When the counter is negative one thread is blocked before entering the critical section while the other thread is still executing code within this critical section. The first thread sets the global_variable and the second one uses it to do a calculation.
If the first thread decrements the counter and is then preempted, the second thread also decrements the counter and evaluates it afterwards. Both threads can't continue since the counter is at -1 now. There is a deadlock situation in the executed program.
This problem can also arise at a higher level of abstraction. The deadlock situation in petri nets will be described in the following section.