Synchronization 3 & Scheduling

• The Pintos project has been posted.
• There are slip days for project milestones.
  • In lecture 5, the professor was still unsure whether the number was two or three.
  • In lecture 6, this was clarified: there are four slip days across all four projects.
• Slip days are based on the commit timestamp in the branch used for submission.
• The recommendation is not to rely on them, but to reserve them for emergencies.
• The TAs offer walkthrough sessions for the first Pintos project and source code.
  • These are meant especially for environment issues, build problems, editor/container setup problems, and general project-startup confusion.

Earlier lectures treated semaphores as a convenient abstraction:

• They provide portable synchronization.
• Threads can wait efficiently.
• Waiting threads do not have to busy-wait.
• They can be used for both:
  • mutual exclusion,
  • condition synchronization.

However, hardware does not directly provide this high-level abstraction.

The operating system has to implement semaphores using lower-level mechanisms such as:

• interrupt control,
• atomic hardware instructions,
• scheduler support,
• wait queues.

The important point is:

A semaphore is not just an integer. It is an integer plus scheduler-visible waiting behavior.

The OS needs semaphores in two places.

A semaphore is conceptually:

typedef struct {
    int count;
    wait_queue q;
} Semaphore;

It contains:

• a counter,
• a queue of waiting threads/processes.

The two operations are:

• P(), also called:
  • wait,
  • down,
  • acquire.
• V(), also called:
  • signal,
  • up,
  • release.

The counter is just a machine word, but the wait queue is not.

The implementation must atomically manipulate:

• the counter,
• the wait queue,
• the current thread state,
• the scheduler’s ready/waiting structures.

There is no single hardware instruction that atomically says:

Check the semaphore counter, enqueue the current thread if needed, block the thread, and later wake it safely.

So semaphores must be built from lower-level primitives.

On a uniprocessor, only one CPU core is executing kernel code.

If interrupts are disabled, then the currently executing kernel code will not be preempted by a timer interrupt or device interrupt.

Therefore:

On a uniprocessor, disabling interrupts briefly can make a critical section atomic with respect to thread interleavings.

But this only works if interrupts are disabled for a very short time.

Disabling interrupts for too long is bad because:

• timer interrupts cannot happen;
• device interrupts cannot be handled;
• the system becomes unresponsive;
• scheduling is delayed;
• I/O latency increases.

A simplified implementation:

void P(Semaphore *s) {
    Disable interrupts;

    while (s->count <= 0) {
        set_state(current_thread, WAITING);
        add_to_queue(&s->q, current_thread);

        Enable interrupts;
        schedule();              /* context-switch away */
        Disable interrupts;
    }

    s->count -= 1;

    Enable interrupts;
}

A simplified implementation:

void V(Semaphore *s) {
    Disable interrupts;

    s->count += 1;

    if (!isEmpty(&s->q)) {
        waiting_thread = RemoveFirst(&s->q);
        set_state(waiting_thread, READY);
        add_to_ready_queue(waiting_thread);
    }

    Enable interrupts;
}

Pintos defines a semaphore roughly as:

struct semaphore {
    unsigned value;       /* Current value. */
    struct list waiters;  /* List of waiting threads. */
};

Important details:

• value is unsigned, so it cannot be negative.
• waiters is a list of blocked threads waiting on this semaphore.

Pintos uses sema_down() for the P/down/wait operation.

Important features:

• it disables interrupts;
• it stores the previous interrupt level;
• it loops while the semaphore value is zero;
• it pushes the current thread onto the waiters list;
• it blocks the current thread;
• after waking, it decrements the value;
• finally, it restores the old interrupt level.

The relevant idea:

old_level = intr_disable();

while (sema->value == 0) {
    list_push_back(&sema->waiters, &thread_current()->elem);
    thread_block();
}

sema->value--;

intr_set_level(old_level);

Pintos uses sema_up() for the V/up/signal operation.

Conceptually:

old_level = intr_disable();

if (!list_empty(&sema->waiters)) {
    thread_unblock(...);
}

sema->value++;

intr_set_level(old_level);

Important points:

• sema_up() may be called from an interrupt handler.
• It does not sleep.
• It wakes a waiting thread, if any.
• It increments the semaphore value.
• The whole operation is protected by disabling interrupts.

On a uniprocessor:

Disabling interrupts prevents interleaving on the only CPU.

On a multiprocessor:

Disabling interrupts only affects the current core.

Other cores may still be running and may still access the same semaphore structure.

Therefore, disabling interrupts does not protect against:

• concurrent updates by other cores,
• simultaneous access to the semaphore counter,
• simultaneous manipulation of the wait queue.

So the uniprocessor semaphore implementation is not correct on a multiprocessor.

We need synchronization across cores.

The semaphore state must be protected by a lower-level multiprocessor-safe primitive.

The lecture introduces:

a spin lock protecting the semaphore state.

A multiprocessor semaphore can be represented as:

typedef struct {
    spin_lock_t slock;
    int count;
    wait_queue q;
} Semaphore;

The spin lock protects:

• count,
• q,
• any state transitions associated with the semaphore.

Simplified implementation:

void P(Semaphore *s) {
    Disable interrupts;
    spin_lock(&s->slock);

    while (s->count <= 0) {
        set_state(current_thread, WAITING);
        add_to_queue(&s->q, current_thread);

        spin_unlock(&s->slock);
        Enable interrupts;

        schedule();              /* context-switch away */

        Disable interrupts;
        spin_lock(&s->slock);
    }

    s->count -= 1;

    spin_unlock(&s->slock);
    Enable interrupts;
}

Simplified implementation:

void V(Semaphore *s) {
    Disable interrupts;
    spin_lock(&s->slock);

    s->count += 1;

    if (!isEmpty(&s->q)) {
        waiting_thread = RemoveFirst(&s->q);
        set_state(waiting_thread, READY);
        add_to_ready_queue(waiting_thread);
    }

    spin_unlock(&s->slock);
    Enable interrupts;
}

There is no need to release and reacquire the spin lock inside V(), because V() does not sleep.

Busy-waiting is usually bad.

But spin locks can be acceptable under special kernel conditions:

• the critical section is very short;
• the lock is held only briefly;
• the code does not sleep while holding the spin lock;
• interrupts are disabled while holding the spin lock, preventing preemption on the same core;
• contention is expected to be rare.

The worst case for a spin lock is:

The lock holder is preempted while holding the lock, and another core spins waiting for it.

Disabling interrupts while holding the spin lock helps avoid this scenario on the local core.

Spin locks require hardware-provided atomic instructions.

The lecture discusses two families:

1. Test-and-set.
2. Load-linked / store-conditional.

An atomic test-and-set operation (x86) does roughly:

old = *x;
*x = 1;
return old;

But the read and write happen atomically.

Meaning:

• if the old value was 0, the caller successfully changed it to 1;
• if the old value was 1, someone else already held the lock.

Lock convention:

• 0 means unlocked;
• 1 means locked.

The lecture presents a test-test-and-set lock, often abbreviated TTAS.

typedef volatile unsigned int spin_lock_t;

void spin_lock(spin_lock_t *lock) {
    do {
        while (*lock)
            /* busy-wait */;
    } while (TAS(lock) == 1);

    memory_barrier();
}

void spin_unlock(spin_lock_t *lock) {
    memory_barrier();
    *lock = 0;
}

Load-linked/store-conditional (RISC) is another hardware synchronization mechanism.

It consists of two operations:

The lecture connects this to architecture styles:

• test-and-set is often associated with more CISC-like interfaces, such as x86;
• load-linked/store-conditional is often associated with RISC-style architectures.

But for this course, they are treated as alternative ways to build the same kind of lock.

The spin-lock code includes:

memory_barrier();

This is necessary because modern systems may reorder memory operations.

There are two different sources of reordering:

1. compiler reordering;
2. hardware reordering.

The compiler may reorder instructions to optimize performance.

For example, source code order:

lock();
x = shared_data;
unlock();

The programmer expects the read of shared_data to happen after acquiring the lock and before releasing it.

But an optimizing compiler may try to move instructions unless explicitly told not to.

Therefore, synchronization code must include compiler barriers.

The lecture explains the Linux-style compiler barrier.

It is often implemented as an empty inline assembly block.

Conceptually:

asm volatile("" ::: "memory");

Important points:

• it emits no actual machine instruction;
• it tells the compiler not to reorder memory operations across it;
• the "memory" clobber tells the compiler to assume memory may have changed;
• inline assembly acts as an optimization barrier because the compiler must respect the programmer’s explicit assembly insertion point.

Compiler barriers only constrain the compiler.

They do not necessarily constrain the CPU hardware.

Modern processors may execute memory operations out of program order because of:

• pipelines,
• store buffers,
• load buffers,
• cache hierarchies,
• memory-level parallelism,
• weak memory models.

Therefore, hardware fences are needed.

On x86, examples include:

• mfence: full memory fence;
• lfence: load/read fence;
• sfence: store/write fence.

Linux exposes different kinds of barriers, such as:

• full memory barrier;
• read memory barrier;
• write memory barrier.

For locking:

spin_lock(&lock);
/* critical section */
spin_unlock(&lock);

We want:

• no critical-section memory access to move before the lock acquisition;
• no critical-section memory access to move after the lock release.

So the lock acquire needs a barrier after acquisition:

TAS(lock);
memory_barrier();
/* critical section starts */

And unlock needs a barrier before release:

/* critical section ends */
memory_barrier();
*lock = 0;

The professor describes this as preventing memory accesses from “bleeding out” of the critical section.

A hardware memory barrier is usually emitted via inline assembly.

asm volatile("mfence" ::: "memory");

Since inline assembly is already a compiler optimization barrier, a memory barrier generally also prevents compiler reordering.

Therefore, in spin-lock code, we often see only a memory barrier, not a separate compiler barrier plus a memory barrier.

Lecture 6 spends time clarifying that synchronization performance is heavily affected by cache behavior.

The key point:

Atomic instructions are not always inherently expensive by themselves; they become expensive when they involve cache lines shared across cores.

If a cache line is used by multiple cores:

• cache coherence has to coordinate ownership;
• one core may need exclusive access;
• other cores’ cache copies may need invalidation;
• messages must travel through the cache/interconnect topology.

The lecture discusses that access cost depends heavily on where the data is:

• L1 cache: very fast, only a few cycles;
• L2 cache: slower;
• L3/last-level cache: slower still;
• main memory: much slower.

The gap between CPU speed and memory latency is called the memory wall.

On multicore and multisocket systems:

• cores may be on the same socket or different sockets;
• caches may be shared by some cores but not others;
• accessing data owned by a nearby core may be cheaper;
• accessing data across sockets may be much more expensive.

Thus, synchronization cost is topology-dependent.

When many hardware threads repeatedly perform atomic operations on the same memory location:

• throughput drops;
• cache coherence traffic increases;
• performance scales poorly.

The professor’s high-level takeaway:

Sharing is expensive. To scale, avoid unnecessary sharing.

The lecture mentions that many lock designs exist.

The simple TTAS lock is easy to understand but not always the best-performing lock.

More advanced locks can reduce cache-coherence traffic.

One important example mentioned:

Pintos has a lock abstraction built on top of a binary semaphore.

Conceptually, a Pintos lock contains:

• a binary semaphore;
• a holder field, mainly for debugging and correctness checks.

The semaphore provides the actual synchronization.

The holder field records which thread currently owns the lock.

Pintos locks are non-reentrant.

That means:

A thread that already holds a lock is not allowed to acquire it again.

Why?

If a thread tries to acquire a lock it already holds, it would block waiting for itself to release the lock.

That causes self-deadlock.

So Pintos includes assertions such as:

ASSERT(!lock_held_by_current_thread(lock));

This gives a useful error message instead of silently freezing.

When acquiring the lock:

1. the thread first acquires the underlying binary semaphore;
2. then it sets holder = current_thread.

This is safe because once the semaphore is acquired, no other thread can hold the lock at the same time.

When releasing the lock:

1. the holder is cleared;
2. then the semaphore is released.

This is also safe because the releasing thread still holds the lock while clearing the holder.

The professor discusses a subtle question:

Is checking the holder field itself synchronized?

There can be a race where another thread changes the holder field while some observer reads it.

But in the specific assertion:

lock_held_by_current_thread(lock)

we only care whether the holder equals the current thread.

Suppose thread C is checking whether it holds the lock.

Other threads A and B may acquire/release the lock concurrently.

C may observe:

• holder is A;
• holder is B;
• holder is NULL.

But C should never observe holder as C unless C actually holds the lock.

So even though there is technically a race, it is benign for this check.

This is called a benign race:

There is a race, but all possible race outcomes are acceptable for the property being checked.

This relies on atomic pointer-sized reads/writes. If reads could produce torn or garbage pointer values, the race would not be benign.

The lowest layer provides:

• interrupt control;
• atomic operations;
• cache coherence;
• memory barriers/fences.

But hardware primitives are:

• machine-dependent;
• low-level;
• easy to misuse;
• often cause spinning;
• not convenient for general programmers.

On top of hardware, the OS builds:

• spin locks;
• semaphores.

Spin locks:

• are close to hardware;
• use atomic instructions;
• busy-wait;
• are only appropriate for short kernel critical sections.

Semaphores:

• are higher-level;
• integrate with the scheduler;
• allow threads to block instead of spin;
• provide portable semantics.

Semaphores support common patterns:

Examples covered earlier:

• producer-consumer synchronization;
• reader-writer synchronization.

The important conceptual lesson:

Operating systems build higher-level, portable abstractions by layering them on top of lower-level hardware mechanisms.

Scheduling is the problem of sharing a serially reusable resource among multiple clients.

Examples of resources:

• CPU cores;
• I/O controllers;
• network interfaces;
• bandwidth;
• memory pages;
• storage devices;
• train tracks;
• factory machines.

A schedule determines:

1. in which order clients get the resource;
2. for how long each client may use it.

In OS scheduling, the lecture distinguishes:

• scheduling policy:
  • deciding who should run next;
• dispatching mechanism:
  • the low-level mechanics of actually switching threads.

Scheduling arises naturally when resources are virtualized and shared.

Scheduling may optimize many different goals.

FIFO means:

First in, first out.

Also called:

First come, first served.

Shortest Job First tries to improve average response time.

To avoid the non-preemptive problems of FIFO and SJF, the scheduler needs to regain control.

The CPU is a preemptive resource.

The scheduler regains control through timer interrupts.

The OS sets a timer interrupt so that after some time quantum:

• execution traps into the kernel;
• the scheduler can choose another thread.

Round Robin uses fixed-length time slices.

• Maintain a list/queue of ready threads.
• Give each ready thread up to one time quantum.
• If the thread blocks before the quantum ends, move to the next thread.
• If the thread is still running at the end of the quantum, preempt it.
• Cycle through ready threads repeatedly.

This is preemptive scheduling.

Round Robin solves the worst non-preemptive starvation issues.

If a thread runs forever:

• it only runs for one quantum at a time;
• other ready threads still get CPU time.

If there is a finite number of ready threads:

• every thread eventually gets a turn.

This provides a crude form of fairness.

If the number of ready threads is unbounded, then the delay before a thread gets its next turn can also become unbounded.

In practice, systems impose limits:

• memory limits;
• process/thread limits;
• browser worker limits;
• container or user quotas.

So Round Robin is more robust than SJF but not perfect.

For jobs:

With a 10 ms time slice, the schedule alternates:

A B C A B A B A B A B A A A A

The example response times are:

Average response time:

\[ \frac{150 + 110 + 30}{3} = \frac{290}{3} \approx 96.67. \]

This is:

• worse than SJF in the example;
• better than FIFO in the lopsided example;
• more robust than non-preemptive SJF.

Round Robin may delay a short but urgent job.

Example:

• thread C is short;
• but it may still wait behind A and B for its turn.

In real-time systems, some short jobs are very important.

Example:

• airbag controller;
• sensor processing;
• safety-critical control.

For those, fairness is not enough.

We need priorities or deadlines.

Some work is more important than other work.

Round Robin treats ready threads roughly equally.

But real-time systems need to express that some threads should preempt others.

Each thread gets a static priority.

• The priority is assigned at thread creation/configuration time.
• The scheduler always chooses the highest-priority ready thread.
• If the running thread blocks or completes, choose the next-highest-priority ready thread.
• If a higher-priority thread becomes ready, immediately preempt the current thread.

This is preemptive scheduling.

Different systems use different conventions.

Some systems say:

• larger number means higher priority.

Other systems say:

• smaller number means higher priority.

The lecture example uses:

99 is higher priority than 50, and 50 is higher priority than 1.

Always check the system convention.

Schedule:

B C B A
0 10 20 60 150

Explanation:

• At time 0, A and B are ready.
• B has higher priority than A, so B runs.
• At time 10, C arrives.
• C has higher priority than B, so C preempts B.
• C finishes at time 20.
• B resumes and finishes at time 60.
• A runs last.

For C:

\[ R_C = 10. \]

For B in this example:

\[ R_B = 10 + 50 = 60. \]

B’s response time includes:

• 10 units lost to preemption by C;
• 50 units of B’s own execution.

Fixed-priority scheduling can provide bounded response times for high-priority tasks.

If a critical task has the highest priority, then when it becomes ready:

• it preempts lower-priority work;
• its response time can be bounded by its own execution time plus interference from even higher-priority tasks.

This is why fixed-priority scheduling is widely used in real-time systems.

Lower-priority threads may starve.

If higher-priority threads keep arriving or running, lower-priority threads may never execute.

But in real-time systems, this may be intentional.

The system cares more about important tasks meeting deadlines than about equal treatment.

Therefore, fixed-priority systems require analysis.

To use fixed-priority scheduling safely, one should analyze maximum response times.

Question:

Can every task meet its deadline under the assigned priorities?

If high-priority tasks consume too much CPU, lower-priority tasks may have unbounded response times.

This analysis becomes more complex when tasks recur periodically or sporadically.

Fixed priorities are static.

But urgency often changes over time.

A thread may receive new input and get a new deadline.

Example:

• a network packet arrives and must be processed within some time;
• a periodic task is released and gets a deadline for this instance;
• a project milestone appears and must be completed by a specific date.

EDF uses deadlines directly.

Each ready job/thread activation has a current absolute deadline.

• Always run the ready thread with the earliest deadline.
• If the running thread blocks or completes, switch to the ready thread with the next-earliest deadline.
• If a thread with an earlier deadline becomes ready, preempt the current thread.
• Deadlines are typically updated when new work arrives or at periodic releases.

This is preemptive scheduling.

EDF can be viewed as priority scheduling where:

\[ \text{priority} = \text{urgency determined by deadline}. \]

But unlike fixed priority:

• the priority changes over time;
• each job activation may have a different deadline.

Therefore, EDF is a dynamic-priority algorithm.

Schedule:

A C A B
0 10 20 100 150

Explanation:

• At time 0, A and B are ready.
• A’s deadline 110 is earlier than B’s deadline 200, so A runs.
• At time 10, C arrives with deadline 25.
• C’s deadline is earlier than A’s, so C preempts A.
• C finishes at time 20.
• A resumes and finishes at time 100.
• B runs last.

A fixed priority number has no meaning by itself.

For example, priority 20 could be:

• high priority if all others are 1 and 2;
• low priority if many others are 50, 60, 70.

Fixed priorities are not compositional.

Different teams must coordinate priority assignments globally.

A deadline, however, directly expresses an objective:

This work must be done by this time.

This makes deadlines more compositional:

• one subsystem can assign deadlines based on its own timing requirements;
• another subsystem can do the same;
• integration still needs feasibility analysis, but the meaning of each deadline is local and explicit.

EDF is optimal with respect to meeting hard deadlines on uniprocessors.

Meaning:

If there exists any schedule that meets all deadlines, then EDF will also meet all deadlines.

This is a strong theoretical property.

EDF is not optimal under overload.

If it is impossible to meet all deadlines, EDF does not necessarily minimize the number of missed deadlines.

So EDF gives:

If zero misses are possible, EDF gives zero misses.

But it does not guarantee:

If misses are unavoidable, EDF gives the fewest misses.

EDF is not optimal on multiprocessors.

Reason:

• deadlines express urgency;
• multiprocessor scheduling also requires reasoning about parallelism and sequentiality.

Example intuition:

If one job cannot be parallelized, giving it ten processors does not make it finish ten times faster.

So EDF’s urgency heuristic is not enough for multiprocessor optimality.

EDF is elegant if deadlines are known.

But in general-purpose systems, deadlines are often not explicit.

Example:

• a browser has JavaScript workers;
• rendering, event handling, networking, and user interaction interact;
• the user wants a snappy interface;
• but the OS may not know explicit deadlines for each thread.

Therefore:

The difficult practical question for EDF is often not how to schedule deadlines, but how to obtain meaningful deadlines.

A computer system has many resources:

• CPU;
• disk;
• SSD controller;
• network interface;
• memory;
• GPU;
• other devices.

Overall performance is often determined by the bottleneck resource.

If the system is bottlenecked on disk, adding CPU cores may not help.

A CPU-bound thread mostly uses the processor.

Example:

while (true) {
    compute_without_IO();
}

If given more CPU time, it makes more progress.

An I/O-bound thread uses the CPU briefly and then waits for I/O.

Example:

while (true) {
    compute_1ms();
    block_on_IO_for_10ms();
}

It needs short CPU bursts to submit or process I/O requests.

Then it blocks while the device works.

Suppose:

• thread A is I/O-bound:
  • compute 1 ms;
  • block on I/O for 10 ms.
• thread B is CPU-bound:
  • compute forever.
• Round Robin time slice is 100 ms.

A may run for 1 ms and submit an I/O request.

Then B runs.

The I/O finishes after 10 ms, but B still has most of its 100 ms time slice left.

So A is ready but cannot run immediately.

Result:

• the I/O device sits idle;
• A cannot submit the next I/O request;
• device utilization is poor.

In the lecture example, the I/O device is mostly idle, around only 10% utilized.

If the Round Robin time slice is reduced to 10 ms, then A may run more often.

This can improve I/O utilization.

But there is no universal best time-slice length.

Reasons:

• different devices have different latencies;
• SSDs, disks, networks, and GPUs differ by orders of magnitude;
• threads need different amounts of CPU before submitting I/O;
• workloads change over time.

So:

Choosing a fixed Round Robin quantum cannot generally solve the CPU-bound/I/O-bound interaction problem.

We want I/O-bound threads to run promptly when they become ready.

Reason:

• they need only a little CPU;
• running them quickly can keep I/O devices busy;
• delaying them wastes non-CPU resources.

CPU-bound threads are less latency-sensitive:

• they will just compute whenever scheduled;
• delaying them slightly usually does not idle another device.

Thus:

General-purpose schedulers often try to favor interactive or I/O-bound tasks.

Shortest Job First was non-preemptive.

SRPT is the preemptive version.

SRPT means:

Shortest Remaining Processing Time First.

Policy:

• always run the ready thread with the least remaining processing time until it completes or blocks;
• if a new ready thread has less remaining time than the current one, preempt immediately.

This is preemptive scheduling.

SJF:

• chooses the shortest job;
• does not preempt once dispatched.

SRPT:

• always chooses the job with shortest remaining time;
• may preempt when a shorter job becomes ready.

SRPT naturally favors short CPU bursts.

Thus, it handles I/O-bound tasks well:

• an I/O-bound thread wakes up;
• it likely needs only a short CPU burst;
• SRPT preempts long CPU-bound work to run it;
• the I/O-bound thread submits the next I/O request quickly;
• the I/O device stays busy.

SRPT adapts automatically to device latencies and CPU burst lengths.

SRPT requires knowing remaining processing time.

Again, this is generally impossible exactly.

The OS cannot solve the halting problem.

So practical schedulers approximate SRPT.

The lecture introduces the locality principle:

Recent past behavior predicts near-term future behavior.

This is not a theorem about all possible programs.

It is an empirical engineering observation.

Most real threads have stable behavior over short time intervals.

Examples:

• if a thread recently did many short I/O bursts, it probably will do more soon;
• if a thread recently used CPU continuously, it probably remains CPU-bound soon.

Threads can change behavior.

Example phases:

1. read data from disk;
2. compute intensively;
3. write results.

So behavior is not fixed forever.

But within a phase, behavior is often regular.

The scheduler can monitor:

• recent CPU usage;
• recent blocking behavior;
• recent sleep/wakeup patterns;
• recent burst lengths.

Then it can estimate:

• whether the thread is CPU-bound;
• whether it is I/O-bound;
• how much CPU it is likely to need soon.

A common method is exponential aging.

Idea:

• combine old estimate with new observation;
• give more weight to recent observations;
• let old behavior fade out exponentially.

Generic form:

where:

\[ 0 \le \alpha \le 1. \]

Large \(\alpha\):

• remembers history longer;
• reacts more slowly.

Small \(\alpha\):

• reacts quickly;
• is noisier.

MLFQ approximates SRPT without knowing future execution times.

It uses feedback from past behavior.

MLFQ has many priority levels.

At each priority level:

• there is a queue of threads;
• Round Robin is used within the level.

Different levels have different time slices:

• high-priority levels use short time slices;
• low-priority levels use longer time slices.

I/O-bound or interactive tasks:

• use CPU briefly;
• block often;
• should remain at high priority;
• get short response times.

CPU-bound tasks:

• use lots of CPU;
• rarely block;
• are gradually demoted;
• get longer time slices at lower priority;
• run efficiently without hurting responsiveness too much.

The scheduler changes priority based on observed behavior.

Rules:

• if a thread uses a lot of CPU, lower its priority;
• if a thread uses CPU sparingly or blocks quickly, raise or maintain its priority.

Thus MLFQ implements the idea:

Recent CPU behavior predicts near-future CPU behavior.

The lecture notes that this style is also known as exponential queues.

Classic Unix, including the 4.4 BSD scheduler, used this general idea for many years.

A practical challenge is measuring CPU usage accurately.

Older systems often used timer ticks.

Example:

• every 10 ms or 100 ms, the timer interrupt fires;
• the kernel charges the currently running thread for CPU usage.

Problem:

• if a thread can predict timer ticks;
• it may block right before the tick;
• another thread gets charged;
• then the original thread wakes up again.

This can trick the scheduler.

The lecture mentions that the Xen hypervisor had a security vulnerability related to this kind of timing/accounting issue.

So precise accounting matters.

MLFQ is elegant and historically important.

But modern general-purpose systems often favor fair scheduling approaches instead.

The lecture then moves to fairness.

Threads do not have feelings, so fairness is not a moral goal.

Fairness is useful because it prevents bad system behavior.

Fairness implies:

• no starvation;
• no thread waits too long relative to its share;
• no single thread can monopolize the resource unfairly;
• resource allocation has predictable semantics.

Fair scheduling is especially useful for general-purpose workloads where:

• explicit deadlines are unavailable;
• fixed priorities are hard to assign;
• many independent programs compete for CPU time.

Suppose:

• resource amount over interval \(\Delta\);
• thread \(i\) has weight \(w_i\);
• total weight is \(\sum_{j=1}^{n} w_j\).

Then thread \(i\)’s fair share is:

\[ \operatorname{share}_i(\Delta) = \Delta \cdot \frac{w_i}{\sum_{j=1}^{n} w_j}. \]

Interpretation:

• if all weights are equal, all threads get equal shares;
• if one thread has twice the weight, it should get twice the resource share.

Example:

If A has weight 1 and B has weight 2, then total weight is:

\[ 1 + 2 = 3. \]

A’s share:

\[ \frac{1}{3}. \]

B’s share:

\[ \frac{2}{3}. \]

So B should receive twice as much CPU time as A.

Lottery scheduling achieves proportional-share fairness randomly.

• Give each thread some number of tickets.
• At each scheduling decision, randomly select one ticket.
• The thread holding the winning ticket runs for one time slice.
• Repeat.

If a thread has more tickets, it has a higher probability of being selected.

If thread \(i\) has \(w_i\) tickets, its probability of winning one lottery is:

\[ \frac{w_i}{\sum_j w_j}. \]

Over time, in expectation, it receives its proportional share.

Lottery scheduling is conceptually simple.

It gives fairness through randomness rather than complicated deterministic tracking.

Lottery scheduling may take time to converge to fairness.

Short-term behavior can be unfair.

A thread may simply be unlucky.

For CPU scheduling, this is often undesirable.

Thus it is mostly interesting as a conceptual technique, not a dominant practical CPU scheduler.

However, randomized allocation ideas may be useful in other resource-management contexts, such as choosing memory pages to evict.

Start-Time Fair Queuing gives deterministic proportional fairness.

The lecture describes it as:

Round Robin, but on virtual time.

Or:

FIFO, but ordered by virtual start time instead of real arrival time.

Each thread has a virtual time \(V_i\).

The scheduler:

• always runs the thread with the earliest virtual time;
• after the thread receives service, advances its virtual time according to its weight.

A high-weight thread’s virtual time advances more slowly.

Thus it is selected more often.

After thread \(i\) receives service amount \(\Delta\):

Since:

\[ \operatorname{share}_i = \frac{w_i}{\sum_{j=1}^{n} w_j}, \]

the update can also be written as:

Interpretation:

• small weight \(\Rightarrow\) small share \(\Rightarrow\) virtual time advances quickly;
• large weight \(\Rightarrow\) large share \(\Rightarrow\) virtual time advances slowly.

The scheduler picks the smallest virtual time, so heavier threads get scheduled more often.

Suppose:

Total weight:

\[ 1 + 2 = 3. \]

Time slice:

\[ \Delta = 10. \]

Starting with:

\[ V_A = 0,\quad V_B = 0. \]

Either A or B can be chosen first. Suppose A is chosen.

After A runs:

\[ V_A = 30,\quad V_B = 0. \]

Now B has smaller virtual time, so B runs.

After B runs:

\[ V_A = 30,\quad V_B = 15. \]

B still has smaller virtual time, so B runs again.

After B runs:

\[ V_A = 30,\quad V_B = 30. \]

Now they tie. Depending on tie-breaking, B may run or A may run.

Over time, the schedule gives:

• A about one third of CPU time;
• B about two thirds of CPU time.

This matches their weights.

A subtle issue:

What virtual time should a thread receive when it wakes up or enters the system?

If it gets virtual time zero, it may unfairly dominate the CPU.

If it keeps an old virtual time from long ago, it may be far behind and get too much service.

If it is set only to current real time, sleeping/I/O-bound threads may be penalized.

The lecture discusses several possible approaches and why naive ones fail.

The course transitions from shared-memory synchronization to CPU scheduling.

Synchronization answered:

How do threads coordinate safely when accessing shared state?

Scheduling asks:

Which thread should run next, and for how long?

The two topics are connected:

• semaphores integrate with the scheduler;
• blocking removes a thread from the ready queue;
• waking adds a thread back to the ready queue;
• locks and semaphores affect which threads are runnable;
• priority scheduling interacts with lock design, leading to issues such as priority inversion and priority inheritance.

The OS builds layers:

1. hardware atomicity and interrupt control;
2. spin locks and memory barriers;
3. semaphores;
4. binary/counting semaphore patterns;
5. producer-consumer and reader-writer algorithms.

This is a classic OS design pattern:

Build convenient, portable abstractions on top of machine-dependent mechanisms.

There is no single perfect scheduler.

Different policies optimize different goals:

1. Semaphores require scheduler integration.
   • Efficient waiting requires blocking, not spinning.
2. On uniprocessors, disabling interrupts can provide short atomic sections.
   • But this does not work on multiprocessors.
3. On multiprocessors, spin locks protect short critical sections.
   • But spin locks require atomic hardware instructions and memory barriers.
4. Memory barriers are necessary because both compilers and CPUs reorder operations.
   • Correct locking must constrain both.
5. Shared memory synchronization can be expensive.
   • Cache coherence and topology matter.
6. Scheduling is policy.
   • Dispatching is mechanism.
7. Different scheduling policies encode different goals.
   • Average response time, fairness, deadline satisfaction, isolation, and throughput can conflict.
8. Exact optimal policies often require impossible knowledge.
   • SJF/SRPT need future execution times.
   • General-purpose OS kernels cannot solve the halting problem.
9. Practical schedulers use approximations.
   • MLFQ uses feedback and locality.
   • Fair schedulers use weights and virtual time.
10. Real systems combine ideas.
    • POSIX real-time scheduling uses fixed priorities.
    • Linux also supports deadline scheduling.
    • General-purpose scheduling often emphasizes fairness and responsiveness.