Lecture 13: Scheduling

Preparation

• Read OSPP §7, Scheduling.
• Skim the Scheduler Activations paper.

Labs

Alex Melnik:

I worked all alone
Just me and my mac
and some bits of poems

• Lab 3
  • distribution of hours
  • exercises
  • double check your region_alloc
• Lab X
  • proposal, demo, grading
  • new TSX issue
• class schedule
  • this Friday: concurrency bugs
  • next week: file systems

uthread from last lecture

• user-mode cooperative context switching
  • Linux/OS X: ucontext
  • Windows: fiber/UMS thread
• virtual CPUs
  • %esp: point to thread state
  • save/restore CPU registers
• questions
  • what’s stack?
  • what does ret return to in uthread_switch.S?
  • what if a uthread runs out of stack?
  • what if a uthread blocks in kernel?
  • what if a uthread loops forever?
  • do uthreads run concurrently?

threads in xv6

• overview
  • 1 user thread and 1 kernel thread per process
  • 1 scheduler thread per processor
  • locks to protect shared data structures and resources
• kernel threads: similar to uthreads, but in kernel mode
  • struct context in proc.h
    • no %eax, %ecx, %edx - who save them?
    • why %eip?
  • cooperative scheduling
    • two switches: thread 1 → scheduler → thread 2
    • scheduler in proc.c
    • swtch in swtch.S
• user threads: preemptive scheduling
  • how to force a thread to give up control?
  • per-processor timer interrupt (every 100 ms): user → kernel
  • trap → yield → sched
  • switch to a different thread, then kernel → user
• scheduling policy: round robin
  • will the thread that called yield run immediately again?
  • can the kernel scheduler coordinate with uthreads?
  • see scheduler activations & more scheduling policies in the textbook
  • 452: more scheduling in distributed systems and data centers
  • what about JOS?

SMP

• SMP: symmetric multiprocessing
  • multiple identical processors
  • each processor has a set of registers
  • share the same memory, IO devices, etc.
  • photos
• terminology
  • APIC (Advanced Programmable Interrupt Controller)
    • recall Intel 82093AA, Figure 2
    • Local APIC
    • I/O APIC
  • ACPI (Advanced Configuration and Power Interface) tables
• SMP booting
  • BIOS boots up a BSP (bootstrap processor)
    • recall single-processor booting: BIOS → bootloader → OS kernel
  • BSP boots up the APs (application processors)
    • discover SMP configuration through the ACPI tables
    • wake up APs with entry address through its Local APIC
  • APs
    • receieve the entry address from BSP and start running
    • in what mode now, real or protected?
    • do we need to set up page tables, interrupt handlers, etc. again for each AP?
    • how to coordinate between multiple processors? lock kernel data structure?
• more on ACPI tables
  • who constructed the ACPI tables? where are they in memory?
  • would the kernel overwrite & corrupt the tables?
  • challenges: High Precision Event Timer (lab 4), PCI Express (lab 5)

Exercise: Barriers

In this assignment we will explore how to implement a barrier using condition variables provided by the pthread library. A barrier is a point in an application at which all threads must wait until all other threads reach that point too. Condition variables are a sequence coordination technique similar to xv6’s sleep and wakeup.

Download barrier.c and compile it on your laptop or attu:

$ gcc -g -O2 -pthread barrier.c
$ ./a.out 2
Assertion failed: (i == t), function thread, file barrier.c, line 55.

The 2 specifies the number of threads that synchronize on the barrier (nthread in barrier.c). Each thread sits in a tight loop. In each loop iteration a thread calls barrier() and then sleeps for some random number of microseconds. The assert triggers, because one thread leaves the barrier before the other thread has reached the barrier. The desired behavior is that all threads should block until nthreads have called barrier.

Your goal is to achieve the desired behavior. In addition to the lock primitives that you have seen before, you will need the following new pthread primitives (see man pthread for more detail):

pthread_cond_wait(&cond, &mutex);  /* go to sleep on cond, releasing lock mutex */
pthread_cond_broadcast(&cond);     /* wake up every thread sleeping on cond */

pthread_cond_wait releases the mutex when called, and re-acquires the mutex before returning.

We have given you barrier_init(). Your job is to implement barrier() so that the panic won’t occur. We’ve defined struct barrier for you; its fields are for your use.

There are two issues that complicate your task:

• You have to deal with a succession of barrier calls, each of which we’ll call a round. bstate.round records the current round. You should increase bstate.round when each round starts.

• You have to handle the case in which one thread races around the loop before the others have exited the barrier. In particular, you are re-using bstate.nthread from one round to the next. Make sure that a thread that leaves the barrier and races around the loop doesn’t increase bstate.nthread while a previous round is still using it.

Test your code with one, two, and more than two threads.