Lab 3 Performance measures of an RTOS with blocking and priority 2 22 2014 Page 3 1 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 Lab2 c and OS h Starter files 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 execution Jonathan W Valvano Lab 3 Performance measures of an RTOS with blocking and priority 2 22 2014 Page 3 2 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 OS AddPeriodicThread will be called 0 1 or 2 times Think about how would your implementation be different if there were 10 background threads Write C code to implement this new expanded periodic thread feature 2 Add features to the OS to measure and record time jitters for the two periodic threads Record two maximum jitters and two histograms of jitter values In particular move the jitter