Course Calendar

We need to work through the rest of our discussion of how a filesystem is layered over raw hardware. We started to explain how basic files—be they text files, audio files, executable images, etc— are segmented into blocked and distributed across free sectors of the hardware. We need to advance that discussion to be clear how filesystem supplorts the notion of a directory, and how an absolute path name like /usr/class/cs110/WWW/index.html can be parsed and translated to an inode number, which is the location within the inode table that stores metainformation about that file and where all of its payload blocks live.

We'll then discuss a few things as a way of transitioning to multiprocessing: how open file sessions are maintained by the OS on a per-process basis, and how system calls differ from traditional function calls. And time permitting, we'll introduce a new system call that's used to spawn new processes.

Your first lab will have you discuss the various ways you can exploit a file system design to implement other functions. You'll also get a chance to play with the stat command line utility and learn some new valgrind tricks.

The lab handout includes a collection of laptop exercises to elevate your gdb and valgrind acumen, though the CA who leads your discussion section may opt to focus on the whiteboard problems and leave the laptop experimentation to you.

We need to discuss signal masks, signal blocking, and how they can be used properly to avoid concurrency issues. We'll start with a contrived example where code is technically capable of executing in an order we don't intend, and we'll use signal masks and blocking to fix the problem. We'll then advance to work through a series of improvements to the simplesh program that we wrote last time.

We'd like you to spend the section studying a parallel implementation of mergesort so you understand its architecture and ultimately believe that it works. Time permitting, we'd like you to work through a collection of short answer questions to solidify your understanding of virtual memory and process scheduling.

We'll then move on to our discussion of mutlithreading and begin to work through the lecture examples We've provided today.

No labs this week

notepad:small Lab 04 Solution

We'd like to spend this week's lab reviewing everything about Assignment 3 that made it challenging. By now, you're well aware how difficult multiprocessing and concurrency can be, and we want to take time to review some of the most important concepts. Problem 1 has you revisit those programs and work through why they needed to be written the way they were.

The remaining three questions all deal with multithreading. We think all three questions are instructive, but it's probably more important to work through problems 2 and 3. Problem 4 is a coding question, and that can be managed independently, outside of lab time.

Ryan Eberhardt, the CS110A CA, is posting some optional extra pre-recorded videos if you're interested in some additional material covering the CS110 systems topics. There's no live session, but feel free to post on Ed or stop by office hours if you want to chat about the material!

We'll work through the implementation of a rwlock class, which is like a traditional mutex, except that it allows multiple threads to be in a critical region, provided none of them need to change any shared data structures.

Once we work through that, we'll move on to another threading construct, called an Event Barrier, for modeling lifting a barrier for threads to continue.

This week's lab will invest some time understanding more about networking. And then we'll work together to implement a collection of simple servers.

We'll spend some time talking about aspects of the ThreadPool assignment and the Proxy assignment, specifically how things for the proxy could have been implemented differently.

This is the last week of section!