Lab 3 Performance measures of an RTOS with blocking and priority 2/22/2014 Page 3.1 Jonathan W. Valvano Lab 3 Performance measures of an RTOS with blocking and priority Goals • Extend the RTOS to include blocking and priority, • Extend the RTOS to include two real-time periodic tasks, • Develop minimally invasive tools to determine performance measures, • Record debugging/performance data and download this data to the PC. Starter files Lab2.c and OS.h Background In this lab you will convert your spinlock semaphores to blocking semaphores, and convert your round robin scheduler to a priority scheduler. A priority field will be added to the TCB, which is set at the time the user calls OS_AddThread. In Lab 2, you implemented a single periodic task using a timer interrupt and a single aperiodic task using the PF4 interrupt. In this lab, you will add the possibility of two periodic tasks and two aperiodic tasks. An additional parameter will allow the user to set the priority of the four background tasks. In the example user program, Lab2.c, one periodic task will sample the ADC and a second periodic task will run a digital PID motor controller. The two aperiodic tasks will be triggered by the two buttons on the board (PF4=SW1 and PF0=SW2). The background tasks should have priority (preempt) any foreground task, regardless of the user-defined priorities. When modifying your Lab2, you will need to uncomment this line in the main() program OS_AddSW2Task(&SW2Push,2); // add this line in Lab 3 A thread is in the blocked state when it is waiting for some external event like input/output (serial input data available, LCD free, I/O device available.) If a thread communicates with other threads then it can be blocked waiting for receive data or waiting for there to be room in the transmit buffer. Both types of blocking that will be implemented in the part of this lab. If a thread wishes to output to the LCD display, but another thread is currently outputting, it will block. We will use a blocking semaphore to implement the sharing of the display output among multiple threads. All of these features can be implemented by changing OS_Wait, OS_Signal, OS_bWait, OS_bSignal, and your scheduler. One possible way to implement blocking semaphores uses linked-list data structures to hold the ready and blocked threads. You will need to create multiple blocked linked lists. In general, you would have one blocked list with each blocking semaphore. You could extend the semaphore structure to include both the semaphore value and a pointer to a TCB list containing threads that are blocked on the semaphore. The semaphore initialization should be extended to clear the linked-list of blocked threads on that semaphore. Except for the semaphore structure, everything else in the user program should remain exactly the same. New OS_Wait 1) Save the I bit, then disable interrupts 2) Decrement the semaphore counter, (*pt->Value) = (*pt->Value)-1 3) If the semaphore counter is less than zero then this thread will be blocked set the status of this thread to blocked, specify this thread is to be blocked onto the linked list of this semaphore (semaphore pointer) suspend thread causing the thread switch operation to occur 4) Restore I bit to its previous value Add this step somewhere in your thread switch process 1) If this thread is to be blocked move the TCB of this thread from the active list to the end of the blocked list of the specified semaphore New OS_Signal 1) Save the I bit, then disable interrupts 2) Increment the semaphore counter, (*pt->Value) = (*pt->Value)+1 3) If the semaphore counter is less than or equal to zero then wake up one thread from the TCB linked list with Round Robin, choose the one waiting the longest (bounded waiting) with Priority, wake up the highest priority thread move the TCB of the “wakeup” thread from the blocked list to the active list what to do with the thread that called OS_Signal with Round Robin, do not suspend executionLab 3 Performance measures of an RTOS with blocking and priority 2/22/2014 Page 3.2 Jonathan W. Valvano with Priority, do suspend execution if you wake up a higher priority thread be careful not to suspend a background thread 4) Restore the I bit to its previous value There is a second simpler implementation. In this implementation, a BlockPt field is added to the TCB. If the BlockPt is null, the thread is not blocked. If the BlockPt contains a semaphore pointer, it is blocked on that semaphore. This simple implementation will not allow you to implement bounded waiting. There are other ways to implement blocking, and you are free to implement other blocking schemes. Although bounded waiting is important, it is not necessary for you to implement it. In uCOS-III, if a low priority thread signals a semaphore that wakes up a higher priority thread, the thread switch occurs immediately, and the higher priority thread is run, without waiting for the time slice of the lower priority thread to finish. This is a good feature, but you do not have to implement it in this lab. You will implement a blocking scheduler. If multiple threads are blocked, when it is time to wakeup a thread, one option is to have the OS wakeup the one that has been blocked the longest (bounded waiting). If a thread requests a resource that is unavailable, your system should move the thread to the appropriate blocked linked-list. Careful thought should go into when to remove a thread from the blocked list. There are lots of ways in which to implement blocking semaphores. You are allowed to choose whichever way you wish as along as 1) Blocked threads are not allowed to run; 2) The Lab3.c user program runs for 30 minutes without crashing; 3) The Lab3.c user program runs for 30 minutes without hitting a deadlock; and 4) You understand how to implement blocking as described in class and as implemented in uCOS-II. Preparation 1) Consider at least two ways to implement the second periodic background thread. A priority parameter in the OS_AddPeriodicThread function allows the user to specify the relative priority of the four background threads. This priority does not affect the fact that all background threads (two periodic, two aperiodic) will preempt any foreground thread. In this lab,