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

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.

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.

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.

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();

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.

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.

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

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 $(10 + 256) * 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

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