Lecture 11: Locking exercises

Preparation

• Read OSPP §6, Multi-Object Synchronization.

More on locks

• spinlocks from last lecture
  • spin on locked (e.g., using xchg)
  • hold for very short times
  • don’t yield CPU while holding lock
  • (un)fairness issues: FIFO ordering?
• alternative: ticket spinlocks
  • real world example: bank, DMV, …
  • use two variables
    • next ticket
    • “now serving” ticket
  • take a number from next & wait until now_serving reaches next
  • try # threads > # CPUs
  • see Linux kernel’s ticket spinlocks

struct lock { _Atomic int next, now_serving; };

void acquire(struct lock *l)
{
  int ticket = atomic_fetch_add(&l->next, 1);
  while (l->now_serving != ticket);
}

void release(struct lock *l)
{
  ++l->now_serving;
}

• many other locks
  • MCS locks
  • “blocking” locks: waiting threads yield the CPU
  • rwlocks (e.g., pthread_rwlock_t)
  • RCU
• alternative: transactional memory
  • example: Intel’s TSX
  • demo using ph.c
    • compile: gcc -mrtm
    • make sure your CPU supports TSX
      • Linux: check for hlm and rtm in /proc/cpuinfo
      • OS X: sysctl machdep.cpu | grep features
      • otherwise, “Illegal instruction”
      • be careful: your CPU might be buggy
    • or, use an emulator: Intel SDE, sde -tsx -- ./a.out 4
  • how do you compare this interface to locks
    • easy to use?
    • performance?
  • ideas for lab X?

#include <immintrin.h>
...
if (_xbegin() == _XBEGIN_STARTED) {
  // do a few things
  _xend();
} else {
  // plan B (e.g., fail or retry)
}

Spinlocks in xv6

• show spinlock.h, spinlock.c
  • xchg and ->locked
  • asm volatile
  • would cpu or compiler reorder things?
• what’s pushcli()?
• can we use ->locked = 0 in release() instead of xchg?

xv6 exercises

Double acquires

Make sure you understand what would happen if the kernel executed the following code snippet:

struct spinlock lk;
initlock(&lk, "test lock");
acquire(&lk);
acquire(&lk);

Feel free to use QEMU to find out; acquire is in spinlock.c.

Race in ide.c

An acquire ensures interrupts are off on the local processor using the cli instruction (via pushcli()), and interrupts remain off until the release of the last lock held by that processor (at which point they are enabled using sti).

Let’s see what happens if we turn on interrupts while holding the ide lock. In iderw in ide.c, add a call to sti() after the acquire(), and a call to cli() just before the release(). Rebuild the kernel and boot it in QEMU. Chances are the kernel will panic soon after boot; try booting QEMU a few times if it doesn’t. Try running QEMU on Linux.

Make sure you understand why the kernel panicked. You may find it useful to look up the stack trace (the sequence of %eip values printed by panic) in the kernel.asm listing.

Race in file.c

Remove the sti() and cli() you added, rebuild the kernel, and make sure it works again.

Now let’s see what happens if we turn on interrupts while holding the ftable.lock. This lock protects the table of file descriptors, which the kernel modifies when an application opens or closes a file. In filealloc() in file.c, add a call to sti() after the call to acquire(), and a cli() just before each of the release()es. You will also need to add #include "x86.h" at the top of the file after the other #include lines. Rebuild the kernel and boot it in QEMU. It will not panic.

Why didn’t the kernel panic? Why do ftable.lock and ide_lock have different behavior in this respect?

You do not need to understand anything about the details of the IDE hardware to answer this question, but you may find it helpful to look at which functions acquire each lock, and then at when those functions get called.

There is a very small but non-zero chance that the kernel will panic with the extra sti() in filealloc(). If the kernel does panic, make doubly sure that you removed the sti() call from iderw.

xv6 lock implementation

Why does release() clear lk->pcs[0] and lk->cpu before clearing lk->locked? Why not wait until after?