Race Conditions

• One process is to execute x x+1
• The other is to execute x x-1
• When both are finished x should be 10
• But we might get 9 and might get 11!
• Show how this can happen (x x+1 is not atomic)
• Tanenbaum shows how this can lead to disaster for a printer spooler

Critical sections

1. No two processes may be simultaneously inside their critical section.
2. No assumption may be made about the speeds or the number of CPUs.
3. No process outside its critical section (including the entry and exit code)may block other processes.
4. No process should have to wait forever to enter its critical section.
   • I do NOT make this last requirement.
   • I just require that the system as a whole make progress (so not all processes are blocked).
   • I refer to solutions that do not satisfy Tanenbaum's last condition as unfair, but nonetheless correct, solutions.
   • Stronger fairness conditions have also been defined.

Mutual exclusion with busy waiting

• Does not work for user-mode programs. So the Unix print spooler would not be helped.
• Does not prevent conflicts between the main line OS and interrupt handlers.
  • This conflict could be prevented by disabling interrupts while the main line is in its critical section.
  • Indeed, disabling (a.k.a. temporarily preventing) interrupts is often done for exactly this reason.
  • Do not want to block interrupts for too long or the system will seem unresponsive.

• Both main lines can conflict.
• One processor cannot block interrupts on the other.

Sleep and Wakeup

Semaphores

1. Mutual exclusion.
2. No speed assumptions.
3. No blocking by processes in NCS.
4. Forward progress (my weakened version of Tanenbaum's last condition).

• A binary semaphore S takes on two possible values “open” and “closed”.
• Two operations are supported
• P(S) is
• while (S=closed) {}
• S<--closed <== This is NOT the body of the while

• That is, wait until the gate is open, then run through and atomically close the gate
• Said another way, it is not possible for two processes doing P(S) simultaneously to both see S=open (unless a V(S) is also simultaneous with both of them).
• V(S) is simply S<--open

• With binary semaphores, two consecutive Vs do not permit two subsequent Ps to succeed (the gate cannot be doubly opened).
• We might want to limit the number of processes in the section to 3 or 4, not always just 1.

• A counting semaphore S takes on non-negative integer values
• Two operations are supported
• P(S) is
• while (S=0) {}
• S--

• That is, wait until the gate is open (positive), then run through and atomically close the gate one unit
• Another way to describe this atomicity is to say that it is not possible for the decrement to occur when S=0 and it is also not possible for two processes executing P(S) simultaneously to both see the same necessarily (positive) value of S unless a V(S) is also simultaneous.
• V(S) is simply S++

• Two classes of processes
  • Producers, which produce times and insert them into a buffer.
  • Consumers, which remove items and consume them.
• What if the producer encounters a full buffer?Answer: It waits for the buffer to become non-full.
• What if the consumer encounters an empty buffer?Answer: It waits for the buffer to become non-empty.
• Also called the bounded buffer problem.
  • Another example of active entities being replaced by a data structure when viewed at a lower level (Finkel's level principle).

• k is the size of the buffer
• e represents the number of empty buffer slots
• f represents the number of full buffer slots
• We assume the buffer itself is only serially accessible. That is, only one operation at a time.
  • This explains the P(b) V(b) around buffer operations
  • I use; and put three statements on one line to suggest that a buffer insertion or removal is viewed as one atomic operation.
  • Of course this writing style is only a convention, the enforcement of atomicity is done by the P/V.
• The P(e), V(f) motif is used to force “bounded alternation”. If k=1 it gives strict alternation.

Semaphore implementation

class semaphore {
    private int count;

    public semaphore (int init)
    {
        count = init;
    }

    public void P ()
    {
        while (1) {
              Disable interrupts;
              if (count > 0) {
                   count--;
                   Enable interrupts;
              } else {
                   Enable interrupts;
              }
        }
    }

    public void V ()
    {
        Disable interrupts;
        count++;
        Enable interrupts;
    }
}

• Turn off all other processors?
• Use atomic “add item” and “take item”, as in "producer-consumer"?

• E.g. Atomic increment.
• E.g. Test and set (IBM solution). Set value to one, but return OLD value. Use ordinary write to set back to zero.
• Read-modify-writes may be implemented directly in memory hardware, or in the processor by refusing to release the memory bus.

class semaphore {
    private int t;
    private int count;
    private queue q;
        
    public semaphore(int init)
    {
        t = 0;
        count = init;
        q = new queue();
    }

    public void P()
    {
        Disable interrupts;
        while (TAS(t) != 0) { /* just spin */ };
        if (count > 0) {
            count--;
            t = 0;
            Enable interrupts;
            return;
        }
        Add process to q;
        t = 0;
        Enable interrupts;
        Redispatch;
    }

    public V()
    {
        Disable interrupts;
        while (TAS(t) != 0) { /* just spin */ };
        if (q == empty) {
            count++;
        } else {
            Remove first process from q;
            Wake it up;
        }
        t = 0;
        Enable interrupts;
    }
}

Mutexes

Monitors

• Shared data.
• Operations on the data.
• Synchronization, scheduling.

class QueueHandler {

    private:
        static int BUFFSIZE = 200;
        int first;
        int last;
        int buff[BUFFSIZE];
        condition full;
        condition empty;

	int ModIncr(int v) {
	    return (v+1)%BUFFSIZE;
	}

    public:
        void QueueHandler (int);
        void AddToQueue (int);
        int RemoveFromQueue ();
    };



    void
    QueueHandler::QueueHandler (int val)
    {
	first = last = 0;
    }

    void
    QueueHandler::AddToQueue (int val) {
    {
	while (ModIncr(last) == first) {
	    full.wait();
	}
	buff[last] = val;
	last = ModIncr(last);
	empty.notify();
    }

    int
    QueueHandler::RemoveFromQueue ();
    {
	while (first == last) {
	    empty.wait();
	}
	int ret = buff[first];
	first = ModIncr(first);
	full.notify();
	return ret;
    }

class QueueHandler {

        final static int BUFFSIZE = 200;
        private int first;
        private int last;
        private int buff[BUFFSIZE];


        private int ModIncr(int v) {
            return (v+1)%BUFFSIZE;
        }

        public QueueHandler (int val)
        {
            first = last = 0;
        }

        public synchronized void AddToQueue (int val) {
        {
            while (ModIncr(last) == first) {
                try { wait(); }
                catch (InterruptedException e) {}
            }
            buff[last] = val;
            last = ModIncr(last);
            notify();
        }

        public synchronized int RemoveFromQueue ();
        {
            while (first == last) {
                try { wait(); }
                catch (InterruptedException e) {}
            }
            int ret = buff[first];
            first = ModIncr(first);
            notify();
            return ret;
        }

• condition.wait(): release monitor lock, put process to sleep. When process wakes up again, re-acquire monitor lock immediately.
• condition.notify(): wake up one process waiting on the condition variable (FIFO). If nobody waiting, do nothing.
• condition.broadcast(): wake up all processes waiting on the condition variable. If nobody waiting, do nothing.

• wait(): release monitor lock on current object; put thread to sleep.
• notify(): wake up one process waiting on the condition; this process will try to reacquire the monitor lock.
• notifyall(): wake up all processes waiting on the condition; each process will try to reacquire the monitor lock. (Of course, only one at a time will acquire the lock.)

• Not present in very many languages (yet), but extremely useful. Java is making monitors much more popular and well known.
• Semaphores use a single structure for both exclusion and scheduling, monitors use different structures for each.
• A mechanism similar to wait/notify is used internally to Unix for scheduling OS processes.
• Monitors are more than just a synchronization mechanism. Basing an operating system on them is an important decision about the structure of the entire system.

Message Passing

• Send: place a message in a mailbox. If the mailbox is full, wait until there is enough space in the mailbox.
• Receive: remove a message from a mailbox. If the mailbox is empty, then wait until a message is placed in it.

Figure 1

• 1-way: messages flow in a single direction (Unix pipes, or producer/consumer):

Figure 2

• 2-way: messages flow in circles (remote procedure call, or client/server):

Figure 3

• Parameters:
• Result:
• Name of procedure:
• Return address:

• Many kinds of applications fit into the model of processing a sequential flow of information, including all of the Unix filters.
• The component parties can be totally separate, except for the mailbox:
  • Less error-prone, because no invisible side effects: no process has access to another's memory.
  • They might not trust each other (OS vs. user).
  • They might have been written at different times by different programmers who knew nothing about each other.
  • They might be running on different processors on a network, so procedure calls are out of the question.

• Relationship between mailboxes and processes:
  • One mailbox per process, use process name in send and receive (simple but restrictive) [RC4000].
  • No strict mailbox-process association, use mailbox name (can have multiple mailboxes per process, can pass mailboxes from process to process, but trickier to implement) [Unix].
• Extent of buffering:
  • Buffering (more efficient for large transfers when sender and receiver run at varying speeds).
  • None -- rendezvous protocols (simple, OK for call-return type communication, know that message was received).
• Conditional vs. unconditional ops:
  • Unconditional receive: return message if mailbox is not empty, otherwise wait until message arrives.
  • Conditional receive: return message if mailbox is not empty, otherwise return special "empty" value.
  • Unconditional send: wait until mailbox has space.
  • Conditional send: return "full" if no space in mailbox (message is discarded).

• Additional forms of waiting:
  • Almost all systems allow many processes to wait on the same mailbox at the same time. Messages get passed to processes in order.
  • A few systems allow each process to wait on several mailboxes at once. The process gets the first message to arrive on any of the mailboxes. This is actually quite useful (give Caesar as an example).
• Constraints on what gets passed in messages:
  • None: just a stream of bytes (Unix pipes).
  • Enforce message boundaries (send and receive in same chunks).
  • Protected objects (e.g. a token for a mailbox).

• Condition variables
• Unix pipes

Classical IPC Problems

Scheduling

• Preemptible: processor or I/O channel. Can take resource away, use it for something else, then give it back later.
• Non-preemptible: once given, it cannot be reused until process gives it back. Examples are file space, terminal, and maybe memory.

• Allocation: who gets what. Given a set of requests for resources, which processes should be given which resources in order to make most efficient use of the resources? Implication is that resources are not easily preemptible.
• Scheduling: how long can they keep it. When more resources are requested than can be granted immediately, in which order should they be serviced? Examples are processor scheduling (one processor, many processes), memory scheduling in virtual memory systems. Implication is that resource is preemptible.

CPU Scheduling

• Running.
• Ready. That is, waiting for CPU time. Scheduler and dispatcher determine transitions between this and running state.
• Blocked. Waiting for some other event: disk I/O, message, semaphore, etc. Transitions into and out of this state are caused by various processes.

• The dispatcher provides the basic mechanism for running processes.
• The scheduler is a piece of OS code that decides the priorities of processes and how long each will run.

• Efficiency of resource utilization (keep CPU and disks busy).
• Minimize overhead (context swaps).
• Minimize response time. (Define response time.)
• Distribute cycles equitably. What does this mean?

FCFS (also called FIFO)

Run until finished.

• In the simplest case this means uniprogramming.
• Usually, "finished" means "blocked". One process can use CPU while another waits on a semaphore. Go to back of run queue when ready.
• Problem: one process can monopolize CPU.

Solution: limit maximum amount of time that a process can run without a context switch. This time is called a time slice.

Round Robin

Run process for one time slice, then move to back of queue. Each process gets equal share of the CPU. Most systems use some variant of this. What happens if the time slice is not chosen carefully?

Originally, Unix had 1 sec. time slices. Too long. Most timesharing systems today use time slices of 10,000 - 100,000 instructions.

Implementation of priorities: run highest priority processes first, use round-robin among processes of equal priority. Re-insert process in run queue behind all processes of greater or equal priority.

Even round-robin can produce bad results occasionally. Go through example of ten processes each requiring 100 time slices.

What is the best we can do?

STCF

Shortest time to completion first with preemption. This minimizes the average response time.

As an example, show two processes, one doing 1 ms computation followed by 10 ms I/O, one doing all computation. Suppose we use 100 ms time slice: I/O process only runs at 1/10th speed, effective I/O time is 100 ms. Suppose we use 1 ms time slice: then compute-bound process gets interrupted 9 times unnecessarily for each valid interrupt. STCF works quite nicely.

Unfortunately, STCF requires knowledge of the future. Instead, we can use past performance to predict future performance.

Exponential Queue (also called "multi-level feedback queues")

Attacks both efficiency and response time problems.

• Give newly runnable process a high priority and a very short time slice. If process uses up the time slice without blocking then decrease priority by 1 and double time slice for next time.
• Go through the above example, where the initial values are 1ms and priority 100.
• Techniques like this one are called adaptive. They are common in interactive systems.
• The CTSS system (MIT, early 1960's) was the first to use exponential queues.

Fair-share scheduling as implemented in Unix:

• Figure out each process' "share" of CPU, based on number of processes and priorities.
• Keep a history of recent CPU usage for each process: if it is getting less than its share, boost priority. If it is getting more than its share, reduce priority.
• Careful: could be unstable!

Summary:

• In principle, scheduling algorithms can be arbitrary, since the system should behave the same in any event.
• However, the algorithms have crucial effects on the behavior of the system:
  • Overhead: number of context swaps.
  • Efficiency: utilization of CPU and devices.
  • Response time: how long it takes to do something.
• The best schemes are adaptive. To do absolutely best, we would have to be able to predict the future.

Priority Inversion Problem

1. P3 enters S, locking the critical section.
2. P3 is preempted by the scheduler and P2 starts running.
3. P2 is preempted by the scheduler and P1 starts running.
4. P1 tries to enter S and is blocked at the P operation.
5. P2 starts running again, preventing P1 from running.

• As long as process P2 is running, process P3 cannot run.
• If P3 cannot run, then it cannot leave the critical section S.
• If P3 does not leave the critical section, then P1 cannot enter.