Odds 'n' Ends, and Mounting File Systems

Wednesday, October 20, 2004

I had neglected to discuss a few items that are quite crucial to operating system design.  Some of these were included here.

Race Conditions

A race condition occurs when two or more processes are competing for resources and, due to when interrupts may occur that result in one process being put to sleep while another progresses, it is unpredictable which process will get to the resource first.

The problem of concurrency is a big issue in operating system design.  Here we are not talking about the problems that arise when a programmer wants to write a program with threads or processes that share data or some other resource, but rather the fact that the various processes running on a particular operating system are, in fact, running concurrently and are sharing kernel and other system resources.  The operating system must be carefully designed and written to make sure that mutual exclusion among processes is enforced where necessary.

Of course, an operating system could provide facilities (system calls) that allow users to handle their necessary concurrency issues more easily.

Interrupts

It is very important to recognize that interrupts happen at the machine language level.  As programmers we often examine our programs in their high level source language form (e.g., C), and can be deceived into thinking that high level language statements are atomic.  Of course, they are not.  So, we may look at an assignment statement like

LOCK = TRUE;

and think that by executing this statement our process has set a shared LOCK variable so that any other process checking the LOCK variable (when its turn to run comes) will necessarily find the variable set to the LOCKED state.  That depends on whether this one statement is translated into more than one machine language instruction or not.  And to make it worse, one would normally have to write something like,

IF NOT LOCK THEN LOCK = TRUE;

leaving even more instructions open for being interrupted.

So, remember that when trying to understand synchronization and mutual exclusion problems, you need to think at the machine language level.

The U-area Open File Table

We pointed out that in the u-area open file table the book shows the first three entries blank.  These are reserved for standard in, standard out, and standard error, which the user does not need to open or close.

Mounting New File Systems

In the traditional Unix view it was possible to have more than one file system on a disk by way of partitions, or on a different device (e.g., a floppy drive).  A separate file system was treated as having a boot block (likely empty, since it would not be used for booting the system), a super block, an inode list, and a list of disk blocks.  In other words, all file systems on Unix were treated as having the same format.  In modern incarnations of Unix, file systems can actually have a different structure.

Consider the case of a disk containing two partitions with two different file systems.  The boot file system (the main one) would be read in and initialized at system startup time.  The second file system would simply look like a single individual file in the main file system.  To have it treated as a file system, that individual file would need to be mounted using the mount system call.  A mount results in attaching (mounting) the file structure for the new file system in any directory of the (super) user's choice. 

Issues that need to be dealt with include how the directory tree is traversed.  That is, when changing directories from a directory in the original file system to a directory in the mounted file system, the algorithms involved (iget and namei) must be able to recognize that the inode for the directory in the mounted file system must be obtained from the inode list in the mounted file system rather than the inode list in the original file system (and vice versa). To resolve this issue the kernel maintains an internal mount table, and inodes have a special field that indicate whether the inode represents a mount point.  The fields in a kernel mount table entry include

We lookied at the algorithms iget and namei in some detail