1. Today From threads to file systems
Final Review
Today
From threads to file systems

2. Threads Threads motivation and concept Threads and processes
User, kernel-level and hybrid threads
Complications with threads
Q: If a multithreaded process forks, a problem occurs if the child gets copies of all the parent’s threads. Suppose that one of the original threads was waiting for keyboard input. Now two threads are waiting for keyboard input, one in each process. Does this problem ever occur in single-threaded processes?
Q: In a system using user-level threads, is there one stack per thread or one stack per process? What about when kernel-level threads are used? Why or why not?
Answer: No. If a single-threaded process is blocked on the keyboard, it cannot fork.
Answer: Each thread calls procedures on its own, so it must have its own stack for the local variables, return addresses and so on. This is equally true for user-level as for kernel-level threads.

3. Thread synchronization
Race conditions and critical sections
Requirements for a solution
Locks and lock implementation
Disabling interrupts and TSL
Busy waiting, priority inversion and sleeping
Basic lock-based data structures
Q: Can two threads in the same process synchronize using a kernel semaphore if the threads are implemented by the kernel? What if they are implemented in user space? Assume that no threads in any other processes have access to the semaphores.
Answer: With kernel threads, a thread can block on a semaphore and the kernel can run some other thread in the same process. Consequently, there is no problem using semaphores. With user-level threads, when one thread blocks on a semaphore, the kernel thinks the entire process is blocked and does not run it ever again. Consequently, the process fails.

4. Synchronization II Condition variables Semaphores
Bounded buffer problem
Reader-writers problem
Issues with semaphores
Monitors
Q: Give a sketch of how an operating system that can disable interrupts could implement semaphores.
Q: Write (pseudocode) a monitor that implements an alarm clock that enables a calling program to delay itself for a specified number of time units (ticks). You may assume the existence of a real hardware clock that invokes a procedure tick in your monitor at regular intervals.
To do a semaphore operation, the OS will first disable interrupts. Then it can read the value of the semaphore. If it is doing a DOWN and the semaphore is equal to zero, it puts the calling process on a list of blocked processes associated with the semaphore. If doing an UP, it must first check to see if there are processes blocked in the semaphore. If there are, one of them is removed from the list and made runnable. When all these operations have been completed, interrupts can be enabled again.

5. Monitor for an alarm clock
monitor alarm {
condition c;
void delay(int ticks) {
int begin_time = read_clock();
while (read_clock() < begin_time + ticks) c.wait(); }
void tick() {
c.broadcast();

6. Deadlocks Deadlock definition Condition for deadlocks
Modeling deadlocks
Deadlock detection and recovery
Dynamic deadlock avoidance
Deadlock prevention
Q: A system has two processes and three identical resources. Each process needs a maximum of two resources. Is deadlock possible? Explain your answer.
The system is deadlock free. Suppose that each process has one resource. There is one resource free. Either process can ask for it, get it and terminate releasing both resources it holds. Thus, deadlock is impossible.

7. I/O Principles of I/O hardware I/O software layers
Ways I/O can be done
Disks
Disk scheduling
RAID
Q: A computer manufacturer decides to redesign the partition table of a Pentium hard disk to provide more than four partitions. What are some consequences of this change?
One obvious consequence is that no existing operating system will work because they all look there to see where the disk partitions are. Changing the format of the partition table will cause all operating systems to fail.

8. File systems interface
File system abstractions – files and directories
Implementing files
Implementing directories
Protection
Q: A key issue when designing a file system is deciding how to keep track of which disk block goes with which file. Of the approaches discussed in class, which one would you choose to maximize efficiency in terms of speed of access, use of storage space, and ease of updating (adding, deleting, modifying) when the data is:
Updated very infrequently and accessed frequently in random order.
Updated frequently and accessed in its entirety relatively frequently.
Updated frequently and accessed frequently in random order.
A: Continual allocation
B: Linked list
C: Either i-node or FATs

9. File systems implementation
Early FS examples – CP/M, MSDOS, Original Unix
FFS
Fsck and journaling
Log file system
Q: In UNIX System V, the length of a block is 1Kbyte and each block can hold a total of 256 block addresses. Using the i-node scheme, what is the maximum size of a file? (Remember UNIX System V uses three levels of indirection)
Q: How many disk operations are needed to fetch the i-nod e for the file /home/fabianb/courses/eecs343/final10.tex? Assume that the i-node for the root directory is in memory, but nothing else along the path is in memory. Also, assume that all directories fit in one disk block.
The i-node itself stores the addresses of the first 10 data blocks. For larger files, the last three addresses point to a single, a double and a triple indirect block. With each block holding 256 block addresses, the maximum file size is $( ) * 1 Kbyte + 256^2 * 1 Kbyte + 256^3 * 1 Kbyte \approx 16 Gbytes.
Directory for /
i-node for /home
Directory for /home
i-node for /home/fabianb
Directory for /home/fabianb
i-node for /home/fabianb/courses
Directory for /home/fabianb/courses
i-node for /home/fabianb/courses/eecs343
Directory for /home/fabianb/courses/eecs343
i-node for /home/fabianb/courses/eecs343/final10.tex

10. Research papers
Scheduler Activations: Effective Kernel Support for the User-Level Management of Parallelism, T. Anderson et al., Proc. of SOSP 1991
Experiences with Processes and Monitors in Mesa, B. Lampson and D. Redell, CACM 1980
Design and implementation of the log-structured file system, M. Rosenblum and J. Ousterhout, Proc. of SOSP 1991