How does the mutex really tell when it can go to zero if it is only 1 bit? Because a mutex can only be held by one thing, and only the process/thread holding it should release it. Remember that these things are a way for programmers to protect their code from itself - if the programmer does it wrong, the OS doesn't care. What does a semaphore do again? Is it like a lock? It's basically like a lock that can be held by a certain (predetermined) number of things. You could listen to music in those headphones during lecture - might be fun... When my voice is that bad already, you don't want to hear me sing. You could now move to "Vivek Pai: Unplugged" lectures once the cold drops - might boost attendance... Luckily, I work at Princeton, where my pay doesn't really get affected by how many students take my class. Otherwise, I might be tempted to make the class really easy and swell the ranks. Is there a "correct" OS? Meaning is there an OS that's been examined and shown to be without bugs? The closest thing to that might be OpenBSD, which focuses on security, but even they find bugs every now and then. If you mean an OS that actually does everything correctly, I think that's beyond the scope of any formal methods for any reasonably-sized OS. If you mean is there an OS that I like, I'm fond of FreeBSD, but have to admit that application support for it isn't great. On a context switch, does the hardware pipeline have to be drained, like in a branch? I assume you mean a mispredicted branch, right? In any case, if we're talking about full context switches, they're getting invoked by a timer going off or the process doing something that blocks/yields (and hence involves the OS). So, the pipeline would have been drained for the interrupt itself. I don't understand the point of the loop in slide 19 If you're trying to acquire and someone else is holding the lock, you need to let them run - they'll eventually finish what they're doing and release the lock. So, when we re-enable interrupts, that'll include the timer interrupt that enables pre-emptive scheduling to occur. So, at some point in that loop, between the enable and disable, the process holding the lock will run and release it. I don't understand how enqueue and dequeue in slide 20 Each lock has a linked list associated with it, and the process is just being added to that linked list if it can't get the lock. Likewise, when process gives up a lock, we have to check if anything else was waiting on it. What was the name of the company that killed people with the radiation treatment? Therac - see the previous followup for details When Intel says that a processor supports SMP, what does that mean? The main instructions on the processors will be the same, but some of the "glue logic" that connects the processor to the cache/motherboard will be different. So, the support to have different caches send cache lines between each other as different processors use the data probably doesn't need to exist on a standard processor. Would disabling all interrupts prevent a process from ever being killed? Yup. It wouldn't have to give up the CPU if it didn't want to, so it would be in control of the system. Don't forget that the monitor was a Civil War Warship In the words of Johnny Carson, "I did not know that". See http://home.att.net/~iron.clad/ for details On slide 25, when does lock.guard get set to 1 - looks like it's always zero. Note the "TAS" (test and set) at the top - it's always being set to 1 at that point. I'm hungry You're welcome to bring food to class as long as I've managed to grab lunch as well. If you bring food and I haven't eaten, well, things might get ugly...