file:: [ostep_1681115599584_0.pdf](../assets/ostep_1681115599584_0.pdf)
file-path:: ../assets/ostep_1681115599584_0.pdf

- # Part II
- thread
  ls-type:: annotation
  hl-page:: 311
  hl-color:: yellow
  id:: 6433ca28-1bdf-433d-8ed9-0d54bf5ba940
	- share the same address space and thus can access the same data
	- context switch: the address space remains the same
	  hl-page:: 311
	  ls-type:: annotation
	  id:: 6433cb70-d168-4863-8268-1e969df6ce06
	  hl-color:: yellow
	- thread control blocks
	  ls-type:: annotation
	  hl-page:: 311
	  hl-color:: yellow
	  id:: 6433cb56-fbef-46da-83c2-13fa2dba2967
	- thread-local storage: one stack per thread in the address space
	  hl-page:: 312
	  ls-type:: annotation
	  id:: 6433cba2-61bd-4549-a29f-2ad85b3e30cd
	  hl-color:: yellow
	- Why thread?
		- possible speedup through parallelization
		- enable overlap of IO in a single program
		- Though these could be done through multi-processing, threading makes share data easier
- KEY CONCURRENCY TERMS
  ls-type:: annotation
  hl-page:: 323
  hl-color:: yellow
  id:: 6433eabf-48d6-4776-b66f-a5f7804d1ddc
	- **indeterminate**: the results depend on the timing execution of the code.
	- race condition
	  ls-type:: annotation
	  hl-page:: 320
	  hl-color:: yellow
	  id:: 6433e4cc-69e4-4057-8cc6-1766240d82f4
	- A **critical section** is a piece of code that accesses a shared variable (or resource) and must not be concurrently executed by more than one thread.
	  hl-page:: 320
	  ls-type:: annotation
	  id:: 6433e52b-1f38-4f7c-b168-0aed624f9bdf
	  hl-color:: yellow
	- **mutual exclusion**: This property guarantees that if one thread is executing within the *critical section*, the others will be prevented from doing so.
	  hl-page:: 320
	  ls-type:: annotation
	  id:: 6433e566-e6ef-45b3-84b1-eba981be914a
	  hl-color:: yellow
	- Atomicity: *as a unit*, or, *all or none*
	  hl-page:: 321
	  ls-type:: annotation
	  id:: 6433e6a1-407c-4936-b184-dee868ef4107
	  hl-color:: yellow
	- synchronization primitives
	  ls-type:: annotation
	  hl-page:: 322
	  hl-color:: yellow
	  id:: 6433e729-7043-453b-8d60-6e6c41560543
- sane 精神健全的；神志正常的；明智的；理智的
  ls-type:: annotation
  hl-page:: 322
  hl-color:: green
  id:: 6433e6e7-d995-4b69-96b3-261b79f94c1d
- Thread API
  hl-page:: 327
  ls-type:: annotation
  id:: 6433f35b-403b-4b25-b9f9-076e9e34777e
  hl-color:: yellow
	- `pthread_create` `pthread_join` `pthread_mutex_lock` `pthread_cond_*`
- Locks
  ls-type:: annotation
  hl-page:: 339
  hl-color:: yellow
  id:: 6433f45b-0345-4790-8379-3d1a94e57ef5
	- A lock is just a variable
	  hl-page:: 339
	  ls-type:: annotation
	  id:: 6433f4ba-f2e4-4743-a536-e2b7747433b7
	  hl-color:: yellow
		- **lock variable**: some type of variable, which holds the *state* of the lock(and maybe additional data such as its holder or a queue for acquisition)
		- **lock state**: available (or unlocked or free); acquired (or locked or held)
		- **lock routines**:
			- `lock()` tries to acquire the lock. If no other thread holds the lock, the thread will acquire the lock and enter the critical section(become the owner of the lock). Otherwise, it will not return while the lock is held by another thread.
			- `unlock()` : The owner of the lock calls `unlock()`, then it is *available* again. If there are waiting threads, one of them will (eventually) notice (or be informed of) this change of the lock's state, acquire the lock, and enter the critical section.
		- Locks help transform the chaos that is traditional OS scheduling into a more controlled activity
		  hl-page:: 340
		  ls-type:: annotation
		  id:: 6433f5e6-bc06-42a9-866e-e9a3053f528f
		  hl-color:: yellow
	- Controlling Interrupts
	  ls-type:: annotation
	  hl-page:: 342
	  hl-color:: yellow
	  id:: 6433fbfd-a1bf-4fd9-a54d-e15189c77b15
		- For *single-processor* systems, **disable interrupts** for critical sections.
		- Problems
			- disable interrupts is privileged. In the worst case, the OS may never regain control when the interrupt isn't going to be enabled.
			- does NOT work on multi-processor systems, each CPU has its own interrupt state
			- importance interrupts may get lost
			- inefficient
	- Just Using Loads/Stores(Fail)
	  hl-page:: 343
	  ls-type:: annotation
	  id:: 6433fe7e-2221-41ee-ad6b-7deaa4459aa5
	  hl-color:: yellow
		- use a simple variable (flag) to indicate whether some thread has possession of a lock
		  hl-page:: 343
		  ls-type:: annotation
		  id:: 6433ff4a-856d-4e4b-af30-6cb600aefeb5
		  hl-color:: yellow
			- On acquisition, load, test the flag. If free, set the flag; If not free, spin-wait(loop load and test).
			- On releasing, clear the flag.
		- Problem
			- When interrupted between load and test, *mutual exclusion* is broken.
			- Low efficiency because of spin-waiting.
	- Spin Locks with Test-And-Set
	  ls-type:: annotation
	  hl-page:: 344
	  hl-color:: yellow
	  id:: 64340154-807c-4a7a-b783-045d5d6d3927
		- **test-and-set (or atomic exchange) instruction**
		  hl-page:: 344
		  ls-type:: annotation
		  id:: 643401e0-fcec-41d3-9898-d5c4175ac464
		  hl-color:: yellow
	-
- efficacy 
  ls-type:: annotation
  hl-page:: 341
  hl-color:: green
  id:: 6433fb69-1425-46b4-996f-f91da5d3e8d0