EL6483: Some Additional Concepts of Real-Time Operating Systems

Size: px

Start display at page:

Download "EL6483: Some Additional Concepts of Real-Time Operating Systems"

Anissa Cummings
5 years ago
Views:

1 : Some Additional Concepts of Real-Time Operating Systems Spring 2016 : Some Additional Concepts of Real-Time Operating Spring Systems / 6

2 Queues Queue: First-In-First-Out (FIFO) data structure often provided as part of RTOS functionalities RTOS-provided queues are thread-safe, i.e., multiple threads can access a queue. Example: one thread which is reading sensor data might put the data samples into the queue; another thread might retrieve data from the queue to process it. Example: multiple threads might write data into the same queue. For example, in a system where we need to write messages to a display, one thread might handle the writing of messages. The messages that are to be displayed could be provided to this thread via a queue. Multiple other threads might put data into this queue to eventually be written to the display. The data size (in bytes) of each element of the queue is usually provided as a parameter when creating a queue. If we want to pass a struct between dierent threads using a queue, we can use the sizeof operator to nd the size of the struct. : Some Additional Concepts of Real-Time Operating Spring Systems / 6

3 Deadlock When we use mutexes/semaphores, we should take care to ensure that there is no situation wherein a thread (or a set of threads) is permanently blocked (e.g., waiting to lock a mutex which cannot possibly be unlocked based on the current system state).for example, consider two mutexes m1 and m2 and two threads: void thread_func1(void *) { } lock_mutex(m1); lock_mutex(m2); // some computation unlock_mutex(m2); unlock_mutex(m1); void thread_func2(void *) { } lock_mutex(m2); lock_mutex(m1); // some computation unlock_mutex(m1); unlock_mutex(m2); : Some Additional Concepts of Real-Time Operating Spring Systems / 6

4 Deadlock Consider the example from the previous page with two mutexes m1 and m2 and two threads. If a thread switch immediately occurs after thread_func1 has locked m1 and then immediately after thread_func2 has locked m2, then each of these two threads would be waiting for a mutex to be unlocked which cannot possibly be unlocked unless one of the threads can somehow run. This is a deadlock. To prevent deadlocks, the sequence of locking/unlocking should be kept track of. Here, a deadlock can be prevented by ensuring that the sequence of locking (e.g., rst m1 and then m2) is the same for both these threads. Another type of deadlock is when a thread has locked a mutex and then tries to lock it again (before unlocking it). Many RTOS mutex implementations can recognize that the same thread had already locked the mutex and simply skip the repeated/redundant locking. Such a mutex implementation is called a reentrant mutex. : Some Additional Concepts of Real-Time Operating Spring Systems / 6

5 Thread Priorities Many RTOS implementations allow assigning priorities to threads. For example, if two threads are both waiting to lock a mutex, then when the mutex becomes available, the higher-priority thread will be given a chance to run. However, if a higher-priority thread is waiting for a mutex which has currently been locked by a low-priority thread, then we might have a priority inversion wherein a medium-priority thread might be chosen to run in preference to the low-priority thread thus indirectly delaying the running of the high-priority thread. For example, consider a high-priority thread thr_h, a medium-priority thread thr_m, and a low-priority thread thr_l. Consider that, at some time, thr_h is waiting for a mutex which has been currently locked by thr_l. Then, purely based on thread priorities, thr_m would be picked to run. Then, the running of thr_l is delayed for some time, thus also delaying of the running of thr_h. A better strategy would be to let thr_l run until it has released the lock for which thr_h is waiting and then let thr_h run before allowing thr_m to run. Such a strategy is called priority inheritance. In the priority inheritance strategy, if a lower-priority thread is holding a lock on a resource which is being waited for by a higher-priority thread (i.e., the lower-priority thread is blocking the higher-priority thread), then the lower-priority thread is temporarily given (i.e., inherits) the priority level of the higher-priority thread. : Some Additional Concepts of Real-Time Operating Spring Systems / 6

6 RTOS schedulers The scheduling algorithm determines when to switch threads. Two commonly used scheduler algorithms are round-robin and earliest-deadline-rst schedulers. Round-robin scheduler: Time slices are assigned to each thread in equal amounts (e.g., a xed number of system ticks) and in circular order. The round-robin scheduler can be combined with priorities wherein a higher-priority thread will be given preference when picking a thread to run. Earliest-deadline-rst scheduler: The RTOS keeps track of deadlines for each thread and picks the thread with the closest deadline. For example, a thread could request be woken up after 10 ms (i.e., delay for 10 ms), this would be registed by the RTOS as a deadline for that thread. : Some Additional Concepts of Real-Time Operating Spring Systems / 6

Operating Systems Structure

Operating Systems Structure Monolithic systems basic structure: A main program that invokes the requested service procedure. A set of service procedures that carry out the system calls. A set of utility