Skip to main content

Section 4.3 Locks

This section covers book chapter 28, on the topic of locks. Start by reading sections 28.1, 28.2, 28.3.

Practice 4.3.1.

Which of the following are possible states for a lock variable?
  • uninitialized
  • available
  • acquired by a single thread
  • acquired by multiple threads
Read section 28.4 about the criteria to use when evaluating lock implementations.

Practice 4.3.2.

Which of the following are objectives of a good lock implementation?
  • Ensuring that if there are timing-related errors in user code, they will be notified at compile time.
  • Ensuring that two threads cannot execute code within a lock-protected region at the same time.
  • Ensuring that all threads contending for a lock-protected region of code get a reasonable chance to run that code at some point.
  • Allowing for optimal use of multiple CPUs.
  • While this is generally a good goal for an OS, it is not directly related to lock implementations.
  • Adding little overhead to the runtime of the program.
Read section 28.5, about the use of interrupt-disabling to provide mutual exclusion.

Practice 4.3.3.

What are the disadvantages of doing locking via disabling interrupts?
  • It is simple to implement.
  • That’s an advantage, not a disadvantage.
  • We are allowing user-controlled threads to perform such a priviledged operation as disabling interrupts. This is too much trust put on the user.
  • It won’t work reasonably with multiple CPUs.
  • Turning off interrupts for long periods of time can lead in lost interrupts and missed behavior (e.g. a disk read getting lost).
Read section 28.6, about a first attempt at locks using a simple flag load-store.

Practice 4.3.4.

Figure 28.2 describes the one of the problems with the simple flag value-setting as a locking mechanism. What problem does it demonstrate?
  • Multiple threads might all be stuck waiting for the flag to clear but noone being able to do so.
  • It can happen the multiple threads enter the critical section at the same time.
  • A thread might spin-wait and waste many cycles doing nothing.
  • While this is a problem with the overall approach, that is not the problem that Figure 28.2 demonstrates.
Read section 28.7, about the test-and-set instruction. Make sure you understand why the code in Figure 28.3 works.

Practice 4.3.5.

    True or False: The test-and-set approach requires support from the hardware, in the form of appropriate new instructions.
  • True.

  • False.

Practice 4.3.6.

    True or False: The test-and-set approach solves the problem of having the thread spin-wait for its turn.
  • True.

  • It doesn’t solve that problem, but it does solve the problem of actually achieving mutual exclusion.
  • False.

  • It doesn’t solve that problem, but it does solve the problem of actually achieving mutual exclusion.
Read section 28.8, about evaluating spin locks.

Practice 4.3.7.

    True or False: Spin locks perform poorly on single-CPU systems, but reasonably on multi-CPU systems.
  • True.

  • False.

Read section 28.9 about the compare-and-swap primitive.
Skip sections 28.10 and 28.11.
Read sections 28.12 and 28.13, about one alternative to spinning.

Practice 4.3.8.

    True or False: A lock system based on yielding can still perform poorly if many threads contend for the same lock.
  • True.

  • False.

Read section 28.14 about using a queue and sleeping infrastructure.
The remaining sections are optional.
You have attempted of activities on this page.