ECEN 5623

Assignment #2 -- RT-Linux User Space and Kernel Threads

Format: Plain text, Rich text, PDF, or MS Word

Code Format: Turn in all code in a tar or zip file!

Upon Completion upload to culearn.colorado.edu, "Lab Assignments, Lab 2".

(If there is a problem with culearn, then E-mail to siewerts@colorado.edu with subject line "LAB SUBMISSION 2" (subject line must be all caps exactly as it appears between quotes) and CC the TA.)

Be sure to include all source code with your submission.

All Group Design Assignments should be submitted to culearn.

(If there is a problemwith culearn, then E-mail siewerts@colorado.edu with subject "GROUP SUBMISSION 2")

Group submission should be in an MS Word or text document with all group members clearly identified on a cover page! Only ONE submission needs to be made for all in the group.

Lab learning objectives are: understand user space pthreads and synchronous communication via message queues and difference between standard and heap message passing, use of threads in the Linux kernel and kernel modules, an understanding of preemption, dispatch, and what the user space and kernel space options are in Linux for implementation of a service - finally, to understand Linux relative time and timers that implement time-outs for blocking and provide time-stamps of various resolutions.

Problem 1 [10 pts] -- Read Sha, Rajkumar, et al paper, "Priority Inheritence Protocols: An Approach to Real-Time Synchronization". Read my summary paper on the topic as well. Finally, read the positions of Linux Torvalds as described by Jonathan Corbet and Ingo Molnar and Thomas Gleixner on this topic as well. Take a position on this topic yourself and write at least one well supported paragraph or more to defend your position based on what we have learned in class. Does the PI-futex that is described by Ingo Molnar provide safe and accurate protection from un-bounded priority inversion as described in the paper? If not, what is different about it?

Problem 2 [5 pts] -- Review the terminology and describe clearly what it means to write "thread safe" functions that are "re-entrant". There are three main ways to do this: 1) pure functions that use only stack and have no global memory, 2) functions which use thread indexed global data, and 3) functions which use shared memory global data, but synchronize access to it using a MUTEX semaphore critical section wrapper. Describe each, providing an example using RT-Linux Pthreads if you wish, and why it is thread safe.

Problem 3 [15 pts] -- Review heap_mq.c and posix_mq.c. First, re-write the VxWorks code so that it uses RT-Linux Pthreads (FIFO) instead of VxWorks tasks, then write a brief paragraph describing how these two message queue applications are similar and how they are different. You may find the following Linux POSIX demo code useful, but make sure you not only read and port the code, but that you build it, load it, and execute it to make sure you understand how both applications work and prove that you got the POSIX message queue features working in Linux. Run both strace and ftrace which also has documentation for ftrace setup - trace on both your Linux host system and try to run this same code on your Beagle xM target and determine if it works there and explain why or why not.

Problem 4 [15 pts] -- Write an RT-Linux user-space Pthread (FIFO) program which spawns two threads: A and B. A should initialize and enter a while(1) loop in which it posts (unlocks) a global semaphore S1 and then does a semaphore lock on a different global semaphore S2 in the process that contains the two Pthreads. B should initialize and enter a while(1) loop in which it does a lock on S1, delays 1 second, and then does a post (unlock) to S2. Test your code on a your host Linux system first and then your target Beagle xM system and turn in all source with evidence that it works correctly (e.g. show me counters that increment in syslog /var/log/messages dump with timestamps).

Problem 5 [15 pts] -- First, on your host, install Kernelshark with "sudo apt-get install kernelshark". Now run the code in Problem #4 on your host Linux system and analyze a Kernel Shark trace for it. Capture the Kernel-Shark trace and add annotations by hand clearly showing semaphore unlock and lock events, the execution time, delay time, and note any unexpected aspects of the trace. Repeat the same analysis on your Beagle xM using either strace or ftrace if possible and account for any differences you see between your host-based trace and target Beagle xM trace. If strace/ftrace on the Beagle xM is not possible, compare to your syslog time-stamped trace output that you built into your code in Problem #4.

Problem 6 [20 pts] -- Modify your RT-linux thread code as implemented in Problem #4 to now run as a kernel module using kernel threads rather than user-space Pthreads. Trace the execution using "printk" at the appropriate "loglevel" so that you can trace execution and prove that your code works with a dump of dmesg - time-stamp your trace using jiffies. Compare to the trace results in Problem #4 and describe any differences you see.

Problem 7 [15 pts] -- Use your kernel thread code from Problem #6 and compare the use of jiffies and the TSC for time-stamping your exeuction. Do you see any difference in timing? Be careful that you account for TSC roll-over and that you read the TSC from just one core if you have a multi-core system. Run this on both your host system and Beagle xM target system - do you see any differences?

Problem 8 [5 pts] -- Based on what you've learned about both user-space Pthreads (FIFO) and kernel-space kernel threads, which do you believe to be a better implementation for real-time services in RT-Linux (in terms of predictable response)? Which approach do you believe to be easier to debug? Please support your position on both questions with examples.