YouTube placeholder

Synchronization Primitives

Race Conditions

A race condition is "when the output of a process is unexpectedly dependent on timing or other events."

Note that the definition of a race depends on what we expected to happen:

  • We expected me to have $4,000 after both deposits. (Otherwise we are not observing the Law of the Conversation of Money, probably important to banks except during bailouts.)

Concurrency v. Atomicity

Concurrency: the illusion that multiple things are happening at once.

  • Requires stopping or starting any thread at any time.

Atomicity: the illusion that a set of separate actions occurred all at once.

  • Requires not stopping certain threads at certain times or not starting certain threads at certain times, i.e. providing some limited control to threads over their scheduling.

Critical Sections

A critical section contains a series of instructions that only one thread can be executing at any given time.

  • This set (or sets) of instructions will look atomic with respect to other threads executing code within the critical section.

void giveGWATheMoolah(account_t account, int largeAmount) {
  int gwaHas = get_balance(account);
  gwaHas = gwaHas + largeAmount;
  put_balance(account, gwaHas);
  notifyGWAThatHeIsRich(gwaHas);
  return;
}
In order to implement the previous example correctly:

  1. What is local state private to each thread? gwaHas

  2. What is the shared state that is being accessed by giveGWATheMoolah? account

  3. What lines are in the critical section? 2-4

Critical Section Requirements

  • Mutual Exclusion: this is the most basic property. Only one thread should be executing in the critical section at one time.

  • Progress: all threads should eventually be able to proceed through the critical section.

  • Performance: we want to keep critical sections as small as possible without sacrificing correctness.

Implementing Critical Sections

  • Two possible approaches. Don’t stop, or don’t enter.

  • On uniprocessors a single thread can prevent other threads from executing in a critical section by simply not being descheduled.

    • In the kernel we can do this by masking interrupts. No timer, no scheduler, no stopping.

    • In the multicore era this is only of historical interest. (This design pattern is usually broken.)

  • More generally we need a way to force other threads—potentially running on other cores—not to enter the critical section while one thread is inside. How do we do this?

Atomic Instructions

Software synchronization primitives utilize special hardware instructions guaranteed to be atomic across all cores:

  • Test-and-set: write a memory location and return its old value.

int testAndSet(int * target, int value) {
  oldvalue = *target;
  *target = value;
  return oldvalue;
}

  • Compare-and-swap: compare the contents of a memory location to a given value. If they are the same, set the variable to a new given value.

bool compareAndSwap(int * target, int compare, int newvalue) {
  if (*target == compare) {
    *target = newvalue;
    return 1;
  } else {
    return 0;
  }
}

  • Load-link and store-conditional: Load-link returns the value of a memory address, while the following store-conditional succeeds only if the value has not changed since the load-link.

y = 1;
__asm volatile(
    ".set push;"     /* save assembler mode */
    ".set mips32;"   /* allow MIPS32 instructions */
    ".set volatile;" /* avoid unwanted optimization */
    "ll %0, 0(%2);"  /*   x = *sd */
    "sc %1, 0(%2);"  /*   *sd = y; y = success? */
    ".set pop"       /* restore assembler mode */
    : "=r" (x), "+r" (y) : "r" (sd));
if (y == 0) {
  return 1;
}

  • Many processors provide either test and set or compare and swap.

  • On others equivalents can be implemented in software using other atomic hardware instructions.

Aside: Shared-Memory Multiprocessing

  • As the number of cores on typical machines has continued to grow, some memory-based synchronization mechanisms have not scaled well.

  • Building more scalable synchronization primitives for cache-coherent shared-memory machines is an open research problem.

    • (The architecture of these machines itself is an open research problem.)

The Bank Example: Test and Set

Let’s modify our earlier example to use a test and set:

void giveGWATheMoolah(account_t account, int largeAmount) {
  int gwaHas = get_balance(account);
  gwaHas = gwaHas + largeAmount;
  put_balance(account, gwaHas);
  notifyGWAThatHeIsRich(gwaHas);
  return;
}
+int payGWA = 0; // Shared variable for our test and set.

void giveGWATheMoolah(account_t account, int largeAmount) {
+ testAndSet(&payGWA, 1); # Set the test and set.
  int gwaHas = get_balance(account);
  gwaHas = gwaHas + largeAmount;
  put_balance(account, gwaHas);
+ testAndSet(&payGWA, 0); # Clear the test and set.
  notifyGWAThatHeIsRich(gwaHas);
  return;
}

Does this work? No! How do I tell if another thread has already set payGWA?

Let’s try again:

void giveGWATheMoolah(account_t account, int largeAmount) {
  int gwaHas = get_balance(account);
  gwaHas = gwaHas + largeAmount;
  put_balance(account, gwaHas);
  notifyGWAThatHeIsRich(gwaHas);
  return;
}
+int payGWA = 0; // Shared variable for our test and set.

void giveGWATheMoolah(account_t account, int largeAmount) {
+ if (testAndSet(&payGWA, 1) == 1) {
+   // But then what?
+ }
  int gwaHas = get_balance(account);
  gwaHas = gwaHas + largeAmount;
  put_balance(account, gwaHas);
+ testAndSet(&payGWA, 0); # Clear the test and set.
  notifyGWAThatHeIsRich(gwaHas);
  return;
}

  • But what should I do if the payGWA is set?

void giveGWATheMoolah(account_t account, int largeAmount) {
  int gwaHas = get_balance(account);
  gwaHas = gwaHas + largeAmount;
  put_balance(account, gwaHas);
  notifyGWAThatHeIsRich(gwaHas);
  return;
}
+int payGWA = 0; // Shared variable for our test and set.

void giveGWATheMoolah(account_t account, int largeAmount) {
+ while (testAndSet(&payGWA, 1) == 1) {
+   ; // Test it again!
+ }
  int gwaHas = get_balance(account);
  gwaHas = gwaHas + largeAmount;
  put_balance(account, gwaHas);
+ testAndSet(&payGWA, 0); # Clear the test and set.
  notifyGWAThatHeIsRich(gwaHas);
  return;
}

Busy Waiting

A- Student B Student Balance

 

 

$1000

 
while (testAndSet(&payGWA, 1));
int gwaHas = get_balance(account);

 

 

 

 
while (testAndSet(&payGWA, 1));
while (testAndSet(&payGWA, 1));
while (testAndSet(&payGWA, 1));
while (testAndSet(&payGWA, 1));
while (testAndSet(&payGWA, 1));
while (testAndSet(&payGWA, 1));
while (testAndSet(&payGWA, 1));
while (testAndSet(&payGWA, 1));

 

The Bank Example: Test and Set

int payGWA = 0; // Shared variable for our test and set.

void giveGWATheMoolah(account_t account, int largeAmount) {
  while (testAndSet(&payGWA, 1) == 1) {
   ; // Test it again!
  }
  int gwaHas = get_balance(account);
  gwaHas = gwaHas + largeAmount;
  put_balance(account, gwaHas);
  testAndSet(&payGWA, 0); # Clear the test and set.
  notifyGWAThatHeIsRich(gwaHas);
  return;
}
What are the problems with this approach?

  • Busy waiting: threads wait for the critical section by "pounding on the door", executing the TAS repeatedly.

  • Bad on a multicore system. Worse on a single core system! Busy waiting prevents the thread in the critical section from making progress!

Locks

Locks are a synchronization primitive used to implement critical sections.

  • Threads acquire a lock when entering a critical section.

  • Threads release a lock when leaving a critical section.

Spinlocks

What we have implemented today is known as a spinlock:

  • lock for the fact that it guards a critical section (we will have more to say about locks next time), and

  • spin describing the process of acquiring it.

Spinlocks are rarely used on their own to solve synchronization problems.

Spinlocks are commonly used to build more useful synchronization primitives.

Created 2/17/2017
Updated 9/18/2020
Commit 4eceaab // History // View
Built 2/4/2016 @ 19:00 EDT