LogSeq/hls__ostep_1681115599584_0.md at 11facbf2ef0e25a6b6caee2ff4f789155117e5a6

catfood/LogSeq

Fork 0

ridethepig 11facbf2ef OSTEP 34

2023-04-13 10:16:50 +08:00

35 KiB

Raw Blame History

file:: 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 collapsed:: true
- 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? collapsed:: true
  - 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 collapsed:: true
- 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 collapsed:: true
- 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 collapsed:: true
- 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 a privileged instruction. In the worst case, the OS may never regain control when the interrupt isn't going to be enabled.
    - 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 lock
  - ((6436aafd-c85f-414c-8aee-acdc71e9138e))
  - Requires a preemptive scheduler(or it may spin forever) and NO fairness guarantee
  - For single processor systems, terrible performance, because the thread holding the lock cannot make any progress to release the lock until it is scheduled again and thus all other threads waiting for the lock can do nothing but spinning even they are scheduled.
  - For multi-processor systems, spin lock may work well when thread B on CPU1 waits for thread A on CPU0, and the critical section is short. Because lock owner keeps making progress, spinning doesn't waste many cycles.
  - Priority Inversion: Threads with high priority wait for locks held by threads with low priority. hl-page:: 355 ls-type:: annotation id:: 6435099b-0834-483e-9ef2-98a0b795cf00 hl-color:: yellow Solution: priority inheritance or give up the priority?
- Test-And-Set (Atomic Exchange) hl-page:: 344 ls-type:: annotation id:: 643401e0-fcec-41d3-9898-d5c4175ac464 hl-color:: yellow
  - Returns the old value pointed to by the old_ptr, and simultaneously updates said value to new.
  - "test" the old value (which is what is returned) while simultaneously "set" the memory location to a new value
  - ((6436af87-3f1b-4ee8-a2c8-4de0f1961f1a))
- Compare-And-Swap hl-page:: 348 ls-type:: annotation id:: 6434f8ac-d762-40a4-abb0-2955c2c8b396 hl-color:: yellow
  - Test whether the value at the address specified by ptr is equal to expected. hl-page:: 348 ls-type:: annotation id:: 6434fab0-08de-4f28-8d8e-f48f7e04aaaa hl-color:: yellow If so, update the memory location with the new value. If not, do nothing. Return the old value at the memory location.
  - ((6436c5c7-32e7-4071-b909-4fdc14bb479d))
  - ((b7679e9b-aabe-4bd3-8c2c-eb0a23fad491))
- load-linked and store-conditional hl-page:: 349 ls-type:: annotation id:: 6434fde1-9d19-4381-805e-f2a972875dc2 hl-color:: yellow
  - The load-linked operates much like a typical load instruction, and simply fetches a value from memory and places it in a register. ls-type:: annotation hl-page:: 349 hl-color:: yellow id:: 6434fe1c-47f3-422c-a317-be72f08d6aef
  - store-conditional only succeeds if no intervening store to the address has taken place. hl-page:: 349 ls-type:: annotation id:: 6434fe62-0e92-4414-86cc-b0c37fcf51ec hl-color:: yellow On success, return 1 and update the value at ptr to value. On failure, return 0 and the value at ptr is not updated.
  - ((6436c620-4884-45a7-9273-b7952a6521ae))
  - ((c38274a9-22dd-40e2-b74a-d3a9be63600e))
- Fetch-And-Add ls-type:: annotation hl-page:: 350 hl-color:: yellow id:: 64350170-c853-4080-9ed1-2777ea3a18c8
  - Atomically increments a value while returning the old value at a particular address
  - ((6436c66c-807b-4e9d-93ed-b1d9703e6dc2))
  - ticket lock hl-page:: 351 ls-type:: annotation id:: 64350331-8fbb-4c41-9ac1-1a4ba852f772 hl-color:: yellow
    - ((6436af5c-0000-4bfb-9a27-1d7cf0a830db))
    - Ensure progress for all threads. Once a thread is assigned its ticket value, it will be scheduled at some point in the future (i.e. it will definitely get its turn as unlock() operations increase global turn value). hl-page:: 351 ls-type:: annotation id:: 64350420-ca8a-4cac-af2f-f4e7deb5d1be hl-color:: yellow In contrast, test-and-set spin lock may starve, if it is very unlucky.(never succeeds in contention)
- Simple Yield Lock hl-page:: 353 ls-type:: annotation id:: 64350781-6995-41db-8b8e-2de0eb84136a hl-color:: yellow
  - yield: a system call that moves the caller from the running state to the ready state, and thus promotes another thread to running. hl-page:: 353 ls-type:: annotation id:: 643507af-1153-46c1-b232-31a9a203e5df hl-color:: yellow
  - ((6436c684-ac4a-4144-9e7e-b4cb8f976c1f))
  - Problem: Starvation is still possible; Context switch overhead, though better than spinning
- Lock With Queues, Test-and-set, Yield, And Wakeup ls-type:: annotation hl-page:: 354 hl-color:: yellow id:: 64350b44-dfae-4544-93f9-ff2b343fefd4
  - The real problem is: We have not much control over which thread to run next and thus causes potential waste. hl-page:: 353 ls-type:: annotation id:: 64350b4e-9559-49d9-aa37-eda9fe425b7f hl-color:: yellow
  - park(): put a calling thread to sleep hl-page:: 354 ls-type:: annotation id:: 64350bfb-64f7-4d41-8cc2-260dbec3372d hl-color:: yellow
  - unpark(threadID): wake a particular thread hl-page:: 354 ls-type:: annotation id:: 64350c01-39bb-4d15-b554-0287b13806ee hl-color:: yellow
  - ((6436b05f-2873-4af4-952c-86d82685b583))
  - When a thread is woken up, it will be as if it is returning from park(). Thus when unpark a thread, pass the lock directly from the thread releasing the lock to the next thread acquiring it; flag is not set to 0 in-between.
  - wakeup/waiting race: If the thread is scheduled out just before it calls park, and then the lock owner calls unpark on that thread, it would sleep forever. hl-page:: 356 ls-type:: annotation id:: 64351ba3-d4b5-4999-bc61-7733d5e0a061 hl-color:: yellow
    - One solution is to use setpark(): indicate the thread is about to park. If it happens to be interrupted and another thread calls unpark before park is actually called, the subsequent park returns immediately instead of sleeping.
- Peterson's algorithm: mutual exclusion lock for 2 threads without hardware atomic instruction. Use 2 intention flags and a turn flag. hl-page:: 345 ls-type:: annotation id:: 6434edd3-2a7b-4e11-af18-29854e628bc6 hl-color:: yellow
- two-phase lock hl-page:: 358 ls-type:: annotation id:: 643522a7-4b16-4998-9b2f-47a852681a16 hl-color:: yellow
  - A combination of spin lock and sleep lock
  - In the first phase, the lock spins for a while, hoping that it can acquire the lock. hl-page:: 358 ls-type:: annotation id:: 6435230e-d84a-4c91-8329-b7608b0d543a hl-color:: yellow
  - A second phase is entered if the lock is not acquired, where the caller is put to sleep, and only woken up when the lock becomes free later. ls-type:: annotation hl-page:: 358 hl-color:: yellow id:: 64352344-d140-468c-987c-e8afa05c2171
- Linux System Call futex hl-page:: 356 ls-type:: annotation id:: 64351e9a-6505-4176-a6fb-ddf63f3245a8 hl-color:: yellow
  - each futex is associated with ==a specific physical memory location==, and ==an in-kernel queue==
  - futex_wake(address) wakes one thread that is waiting on the queue.
  - futex_wait(address, expected) puts the calling thread to sleep, assuming the value at address is equal to expected. If it is not equal, the call returns immediately.
  - Figure 28.10: Linux-based Futex Locks ls-type:: annotation hl-page:: 357 hl-color:: yellow id:: 64352221-d590-4371-a5f0-29e9cfa75ccb
efficacy 功效，效力 ls-type:: annotation hl-page:: 341 hl-color:: green id:: 6433fb69-1425-46b4-996f-f91da5d3e8d0
foil ls-type:: annotation hl-page:: 347 hl-color:: green id:: 6434f523-44b7-40ab-8fea-528969c5acfd
delve 钻研；探究；挖 ls-type:: annotation hl-page:: 349 hl-color:: green id:: 6434fb8c-2b3b-4d80-83fb-3b34da4dcd28
brag 吹嘘；自吹自擂 ls-type:: annotation hl-page:: 351 hl-color:: green id:: 643501c1-f11b-4e85-8125-d2a5a31f69b0
scourge 鞭打；鞭笞；折磨；使受苦难
Lock-based Concurrent Data Structures
ls-type:: annotation hl-page:: 361 hl-color:: yellow id:: 643525b0-e245-489b-877d-a2a1d63e7ea6 collapsed:: true
- Concurrent Counters hl-page:: 361 ls-type:: annotation id:: 643525e5-fb85-48d4-905a-2a88b9ac0b0d hl-color:: yellow collapsed:: true
  - Counter with lock
    - Wrap the all the operations with a single lock.
    - Performance is bad due to lock contention and it gets worse when the number of threads increases.
  - perfect scaling: the increase in thread number doesn't harm the performance hl-page:: 363 ls-type:: annotation id:: 64352751-d9bd-4d5e-a8ba-cd18f86b1a15 hl-color:: yellow
  - approximate counter hl-page:: 363 ls-type:: annotation id:: 64352794-d7c8-42f9-8321-f874967cebf2 hl-color:: yellow
    - represent a single logical counter via ==numerous local physical counters==(one per CPU core), as well as ==a single global counter==. Each actual counter has a ==lock==.
    - To add the counter, acquire the ==local lock== and increase it, thus avoiding contention.
    - To read the counter, acquire the ==global lock== and read.
    - To keep the global counter up to date, the local values are periodically transferred to the global counter and reset, which requires ==global lock and local lock==. A threshold S determines how often this transfer happens, tuning the trade-off between scalability and precision.
- Concurrent Linked Lists ls-type:: annotation hl-page:: 367 hl-color:: yellow id:: 643530d8-9d09-4c8a-9e92-47dfe814ef50 collapsed:: true
  - Again, the simplest way to implement this is to wrap all operations on the list with a single lock.
  - Assuming the malloc is ==thread-safe==, we can improve the code a little by narrowing critical section: only operations on global structure need to be locked.
  - hand-over-hand locking: a lock per node. hl-page:: 369 ls-type:: annotation id:: 64353237-4b74-4148-b7c1-5854d83a18c7 hl-color:: yellow
    - When traversing the list, the code first grabs the next node's lock and then releases the current node's lock.
    - In practice, it ==doesn't work== due to prohibitive overhead
- Concurrent Queues ls-type:: annotation hl-page:: 370 hl-color:: yellow id:: 64353353-9de2-421b-967d-dc80a597eecd collapsed:: true
  - Two locks, head and tail, for enqueue and dequeue operation.
  - Add a dummy node to separate head and tail operation. Without this, dequeue operation needs to acquire both locks in case the queue is empty.
- Concurrent Hash Table hl-page:: 372 ls-type:: annotation id:: 6435360d-c176-494a-9d61-b1fd0107a9bd hl-color:: yellow collapsed:: true
  - instead of having a single lock for the entire structure, it uses a lock per hash bucket ls-type:: annotation hl-page:: 372 hl-color:: yellow id:: 6435363d-c697-42a6-bfd0-8a2332cef394
ubiquitous 似乎无所不在的；十分普遍的 ls-type:: annotation hl-page:: 372 hl-color:: green id:: 6435365a-b5d6-46fc-a9a1-25b0d23aa529
humble 谦逊；低声下气；虚心；贬低 ls-type:: annotation hl-page:: 373 hl-color:: green id:: 6435367f-dd9e-449d-b0e4-3d8c9e14f6c2
sloppy 马虎的，草率的；（衣服）宽松肥大的；太稀的，不够稠的； hl-page:: 376 ls-type:: annotation id:: 643536c8-fc05-4bbe-8d1d-0f4f6d1c4fee hl-color:: green
gross 总的，毛的；严重的，极端的；粗鲁的；臃肿的；粗略的； hl-page:: 378 ls-type:: annotation id:: 643537d3-7d01-442b-b47e-59433c2aa6db hl-color:: green
condition variable
hl-page:: 378 ls-type:: annotation id:: 643537ff-1028-4725-8d7a-c0338cc946d3 hl-color:: yellow
- A ==condition variable== is an explicit queue that threads can put themselves on when some state of execution(condition) is not as desired (by waiting on the condition); some other thread, when it changes said state, can then wake one (or more) of those waiting threads and thus allow them to continue (by signaling). hl-page:: 378 ls-type:: annotation id:: 64353882-7697-4c16-8e53-c8f59ea256c1 hl-color:: yellow
- Operations
  - wait() put the caller to sleep. pthread_cond_wait(pthread_cond_t *c, pthread_mutex_t *m) hl-page:: 378 ls-type:: annotation id:: 643538d5-9ea3-4399-9fa2-d75fdf0e1dd4 hl-color:: yellow
  - signal() wake up a sleeping thread waiting on this condition. pthread_cond_signal(pthread_cond_t *c); hl-page:: 379 ls-type:: annotation id:: 643538de-cc40-4dd2-8f03-9492004f209b hl-color:: yellow
  - The wait() also takes a mutex as a parameter; it assumes that this mutex is locked when wait() is called. The responsibility of wait() is to ==release the lock and put the calling thread to sleep== (atomically); when the thread wakes up, it must ==re-acquire the lock before returning== to the caller. The design is helpful to avoid some race conditions when trying to sleep.
  - use a while loop instead of just an if statement when deciding whether to wait on the condition. ls-type:: annotation hl-page:: 380 hl-color:: yellow id:: 643547c5-1613-49e9-899e-0e86f59a1462
stem (花草的)茎；(花或叶的)梗,柄；阻止；封堵；遏止； hl-page:: 379 ls-type:: annotation id:: 64353eb8-8ed8-4680-a3c0-91608b429408 hl-color:: green
- **stem from sth ** 是…的结果；起源于；根源是
Producer/Consumer Problem hl-page:: 382 ls-type:: annotation id:: 64354974-adea-4b20-90f4-a12ebe1e4d5b hl-color:: yellow
- Mesa semantics: Signaling a thread only wakes them up; it is thus a hint that the state of the world has ==changed==, but there is ==no guarantee== that when the woken thread runs, the state will ==still be as desired==. (Another guy may run before the thread and change the state again) hl-page:: 385 ls-type:: annotation id:: 64354cc4-14c5-408d-b879-7d4d011b2b5c hl-color:: yellow
  - So, always use while loops. While loops make sure the thread wake up in the desired state of world, which tackles the ((64355502-f41f-40dd-b71f-e0abdbc76716)) and provides support for ((64355441-5a1b-4015-baa1-65917526079c)) hl-page:: 386 ls-type:: annotation id:: 64354db0-8c74-4c14-b063-d26378a10555 hl-color:: yellow
- Hoare semantics: provides a stronger guarantee that the woken thread will run immediately upon being woken hl-page:: 386 ls-type:: annotation id:: 64354d46-4286-44fd-9e82-2ba562a50f25 hl-color:: yellow
- Incorrect Solution: single condition variable. The problem arises from the ==undirected wakeup operation==: God knows which thread is to be woken up.
  - Envision multiple consumers and one producer:
    1. producer P1 increases count to 1, signals the CV and sleeps
    2. consumer C1 is awaken, reduces count to 0, signals the CV and sleeps
    3. another consumer C2 is woken up ==by accident==, finds out count is 0, sleeps
    4. In this case, they all sleep and thus nobody will signal any of them
  - If in step 3, the producer P1 is woken up, everything is fine. Obviously, one solution is to ==exert control over which thread is to be woken up==. Well, wake up all threads may also solve this problem, see ((64355441-5a1b-4015-baa1-65917526079c)).
- Correct solution: 2 condition variable.
  - Producer threads wait on the condition empty, and signals fill. Conversely, consumer threads wait on fill and signal empty.
  - ((6436b07d-9279-46bb-9c6b-985eb2324df8))
- spurious wakeups hl-page:: 390 ls-type:: annotation id:: 64355502-f41f-40dd-b71f-e0abdbc76716 hl-color:: yellow
  - In some thread packages, due to details of the implementation, it is possible that two threads get woken up though just a single signal has taken place.
- covering condition hl-page:: 391 ls-type:: annotation id:: 64355441-5a1b-4015-baa1-65917526079c hl-color:: yellow
  - covers all the cases where a thread needs to wake up, other threads simply wake up, re-check condition and go back to sleep
  - pthread_cond_broadcast() wakes up all waiting threads
albeit 尽管；虽然 ls-type:: annotation hl-page:: 390 hl-color:: green id:: 64354f54-b26c-48dc-a328-4ae355b680f3
spurious 虚假的；伪造的；建立在错误的观念（或思想方法）之上的；谬误的 hl-page:: 390 ls-type:: annotation id:: 643554f4-75a7-48fa-9366-87058ee723fb hl-color:: green
Semaphores
hl-page:: 396 ls-type:: annotation id:: 64356d96-cce8-48ad-80f1-e3e02a1a4684 hl-color:: yellow collapsed:: true
- A semaphore is an ==object with an integer value== that we can manipulate with two routines sem_wait() and sem_post(). The initial value determines its behavior, so we need to give it an initial value through sem_init() hl-page:: 396 ls-type:: annotation id:: 64356dba-48b4-49b8-8182-c962f12f03a5 hl-color:: yellow
- Semaphore: Definitions Of Wait And Post ls-type:: annotation hl-page:: 397 hl-color:: yellow id:: 6435744b-a300-40ad-ba91-157666d8cd2a
  - sem_wait(sem_t *s): First decrement the value of the semaphore by one. Then wait if the value of semaphore is negative
  - sem_post(sem_t*s): First increment the value of the semaphore by one. If there is any thread waiting, wait up one of them
  - The value of the semaphore, when negative, is equal to the ==number of waiting threads== hl-page:: 397 ls-type:: annotation id:: 64357512-e25b-4226-961a-caec367fc8a3 hl-color:: yellow
- Binary Semaphores (Locks) ls-type:: annotation hl-page:: 398 hl-color:: yellow id:: 6435753a-65b5-4e46-82bc-54c11c1cd533
  - Initialize semaphore to 1, indicating we only have one piece of resource (the critical section).
  - Wrap the critical section with sem_wait and sem_post
  - When the lock is acquired, the semaphore is 0. On another acquisition request, the value goes to -1, which makes the caller sleep. When the lock is free, the value is decreased to 0 on acquisition, which will not get stuck.
- Semaphores For Ordering (Condition Variable, or Ordering Primitive) hl-page:: 399 ls-type:: annotation id:: 64357930-2d96-4867-bc3d-2fe89990ce5f hl-color:: yellow
  - Initialize the semaphore to 0
  - Consider the join operation. The parent calls sem_waitand the child calls sem_post. In either case, no matter which thread is scheduled first, the semaphore guarantees the desired result.
- The Producer/Consumer (Bounded Buffer) Problem (Again) hl-page:: 401 ls-type:: annotation id:: 64357c6d-381e-492e-b901-095454f5315e hl-color:: yellow
  - 2 semaphores empty and full for coordination between consumer and producer, and 1 semaphore for lock
  - Initialize empty <- MAX, and full <- 0
  - Consumer waits for full and posts empty and conversely, produce waits for empty and posts full
  - Special case for MAX=1
    - When only one slot is available in the buffer, we don't even need a lock! Actually, it is binary semaphore which not only controls the buffer entry but also works as a lock.
    - Otherwise, there will be a ==data race== inside the put/get operation due to potential multi-thread access to these procedures (when MAX > 1, the sem_wait(&empty) may allow in more than one thread).
  - Deadlock avoidance
    - If the lock semaphore is the outmost semaphore, deadlock occurs (the thread may sleep in sem_wait(&empty) with mutex unrelease). Therefore, put the lock inside the empty/full semaphore pair.
  - ((6436bebd-0681-4f94-9d04-4d8e4a554512))
- Readers-Writer Locks ls-type:: annotation hl-page:: 406 hl-color:: yellow id:: 643583b4-26b1-4cbf-801c-11ed6e63976e
  - Either allow ==multiple readers to read== concurrently, or allow ==only one writer to write==.
  - Two sets of operation
    - rwlock_acquire/release_writelock(): simply wait/post the writelock
    - rwlock_acquire/release_readlock(): acquire writelock when the ==first reader acquires==, and release it when the ==last reader releases==
  - ((6436c668-5be8-4ce1-b701-1f2a00d34cc9))
  - Problem: More overhead; Unfairness, writer is much more likely to starve.
    - To tackle the writer starvation problem, we may manually wake up the writers (if ever suspended) every time read lock releases. Wiki
- The Dining Philosophers hl-page:: 408 ls-type:: annotation id:: 643587a7-ade4-4f09-be50-aea233ff02c0 hl-color:: yellow
  - Background setting hl-page:: 408 ls-type:: annotation id:: 6435889f-1375-4b94-8630-b3d0d7bdfa56 hl-color:: yellow
    - 5 "philosophers" around a table. Between each pair of philosophers is a single fork (and thus, 5 total). The philosophers each have times where they think (don’t need forks), and times where they eat. In order to eat, a philosopher needs two forks (left and right). The contention for these forks is our synchronization problem.
  - Solution
    - A semaphore per fork, and helper function left/right(p) which is the fork on philosopher p's left/right.
    - Deadlock: if each philosopher tries to grab the fork on their left first, there will be a deadlock. When all of them get their left-side forks, all of the forks are locked and no one could get their right-side fork.
    - Non-deadlock: force one philosopher to try to grab the right-side fork first
    - ((6436bebd-0681-4f94-9d04-4d8e4a554512))
- Implement Semaphores ls-type:: annotation hl-page:: 411 hl-color:: yellow id:: 643589a6-31e6-4603-9259-999e9c8860f7
  - Implementing Zemaphores With One Lock And One CV: the book authors provide us a simple implement for semaphore. hl-page:: 412 ls-type:: annotation id:: 64358de1-f418-44fd-8a77-bc0faa368059 hl-color:: yellow
  - ((6436c47e-dc86-4452-b9b5-4e7997dbfbfb))
salient 最重要的；显着的；突出的: ls-type:: annotation hl-page:: 397 hl-color:: green id:: 64357404-d348-42b3-96a3-ba28575baa66
ensue 跟着发生，接着发生； ls-type:: annotation hl-page:: 408 hl-color:: green id:: 64358802-3b22-46ed-a0e2-71cc9df69a7b
Throttle 节流阀；风门；喉咙；使窒息；使节流； hl-page:: 411 ls-type:: annotation id:: 64358758-cb9c-4e8d-aaa4-f8e50457db88 hl-color:: green
bog 沼泽；泥塘；使陷于泥沼；使动弹不得 hl-page:: 411 ls-type:: annotation id:: 64358755-1fae-4ea2-93a3-8c9d3d3e11c3 hl-color:: green
ramification (众多复杂而又难以预料的)结果,后果 hl-page:: 410 ls-type:: annotation id:: 64358b0c-e441-4d0a-852d-ecfde369306c hl-color:: green
Non-Deadlock Bugs: A large fraction (97%) of non-deadlock bugs studied by Lu et al. are either ==atomicity violations== or ==order violations==. hl-page:: 420 ls-type:: annotation id:: 64361e4c-62eb-4599-9809-0f77f9ce1cd0 hl-color:: yellow
Deadlock
hl-page:: 420 ls-type:: annotation id:: 64361fb7-5aa6-45cd-8b1e-aa0d0c300ad2 hl-color:: yellow collapsed:: true
- Conditions for Deadlock hl-page:: 422 ls-type:: annotation id:: 64361fd1-49ff-4023-8493-840ac423086a hl-color:: yellow
  - If any of these four conditions are not met, deadlock cannot occur.
  - Mutual exclusion: Threads claim exclusive control of resources that they require
  - Hold-and-wait: Threads hold resources allocated to them while waiting for additional resources
  - No preemption: Resources cannot be forcibly removed from threads that are holding them.
  - Circular wait: There exists a circular chain of threads such that each thread holds one or more resources that are being requested by the next thread in the chain.
- Prevention: break the conditions for deadlock hl-page:: 422 ls-type:: annotation id:: 643620d9-cdb6-4073-89f4-f9f8ac223073 hl-color:: yellow
  - Circular Wait: Never induce a circular wait. hl-page:: 422 ls-type:: annotation id:: 643620fb-edc6-43b2-b4b2-43b010cfc46e hl-color:: yellow
    - total ordering and partial ordering of lock acquisition (think about your Discrete Math, total ordering is a restricted form of partial ordering, in partial ordering, some pairs of elements are not comparable)
    - Anyways, follow some kind of ordering when acquire lock in order to avoid cycles.
    - ENFORCE LOCK ORDERING BY LOCK ADDRESS ls-type:: annotation hl-page:: 423 hl-color:: yellow id:: 64362497-58cd-45da-8ab5-84f96e899e16
  - Hold-and-wait: acquiring all locks at once, atomically. hl-page:: 423 ls-type:: annotation id:: 643625fe-423c-4b18-8c22-32d38720c5d0 hl-color:: yellow
    - Not practical
  - No Preemption hl-page:: 424 ls-type:: annotation id:: 64362632-50e8-41dd-a1bc-bbf3d4312b0f hl-color:: yellow
    - trylock either grabs the lock (if it is available) and returns success or returns an error code indicating the lock is held
    - Instead of blocking at the lock call, give up all previous locks and try over again if some of the locks is not available.
    - ```
    while (true) {
      mutex_lock(&lock1);
      if (mutex_trylock(&lock2) == 0) break;
      else mutex_unlock(&lock1);
    }
```
- livelock problem: in some special cases, two threads may keep trying and giving up locks due to each other's intervention hl-page:: 424 ls-type:: annotation id:: 6436281f-4fdc-4586-83fb-b686cec3b76b hl-color:: yellow
  - random delay before looping back and trying the entire thing over again
- Mutual Exclusion: lock-free data structures hl-page:: 425 ls-type:: annotation id:: 643629ba-e746-41a6-b073-1199b3db3691 hl-color:: yellow
  - use atomic instructions provided by hardware
- Avoidance hl-page:: 427 ls-type:: annotation id:: 64362af4-9b35-4e27-8ba2-0f5f8817526a hl-color:: yellow
  - By careful scheduling, deadlock could be avoided.
  - Limited usage: OS does not always have sufficient knowledge to make deadlock-free scheduling. Such approaches also limit concurrency.
  - Banker's Algorithm
- Detect and Recover ls-type:: annotation hl-page:: 428 hl-color:: yellow id:: 64362c62-3a12-4bcb-95ae-baf1ca69312e
  - Allow deadlocks to occasionally occur, and then take some action once such a deadlock has been detected.
terrific 极好的；绝妙的；了不起的；很大的 ls-type:: annotation hl-page:: 428 hl-color:: green id:: 64362b38-6dfb-4c00-8aa6-b756e8983de4
maxim 格言；箴言；座右铭 ls-type:: annotation hl-page:: 428 hl-color:: green id:: 64362b40-5f07-418f-83f3-c83eb5927c94
nasty 极差的；令人厌恶的；令人不悦的；不友好的 ls-type:: annotation hl-page:: 432 hl-color:: green id:: 64364569-01b4-45e1-83f8-ac1bd8af5850
Event-based Concurrency
hl-page:: 432 ls-type:: annotation id:: 64364585-ace4-4920-87fe-87aad004dffd hl-color:: yellow
- event loop: waits for something to do and then, for each event returned, processes them, one at a time hl-page:: 433 ls-type:: annotation id:: 643658f3-4761-4d0c-b044-4cadcfea27aa hl-color:: yellow
  - event handler ls-type:: annotation hl-page:: 433 hl-color:: yellow id:: 643658f9-5eee-4d1a-a3d6-4f8eb9ed3d7b
- select or poll hl-page:: 433 ls-type:: annotation id:: 64365db8-a249-46bc-bd9c-237251c544b5 hl-color:: yellow
  - Check whether there is any incoming I/O that should be attended to.
  - ```
  int select(
    int nfds,
    fd_set *restrict readfds,
    fd_set *restrict writefds,
    fd_set *restrict errorfds,
    struct timeval *restrict timeout);
```
- Examine if some of their descriptors are ready for reading/writing or have an exceptional condition pending. The first n descriptors are checked in each set hl-page:: 434 ls-type:: annotation id:: 64365eb6-5310-4893-9d11-5e332ef84c4a hl-color:: yellow
- select places the given descriptor sets with ==subsets of ready descriptors==. select() ==returns the total number of ready descriptors== in all the sets. hl-page:: 434 ls-type:: annotation id:: 64365ef8-3c62-4d78-8bc6-d0a4b2c81d49 hl-color:: yellow
- Block IO: NO blocking calls are allowed in event-based systems, because it will just stop the whole process.
- Asynchronous I/O ls-type:: annotation hl-page:: 437 hl-color:: yellow id:: 643693db-d363-46ee-b0d6-910b30408946
  - Issue an I/O request and return control immediately to the caller, before completion. Additional interfaces to determine whether the IOs have completed. hl-page:: 437 ls-type:: annotation id:: 64369701-8a39-4aa4-9985-129572c04f53 hl-color:: yellow
  - AIO control block aiocb
  - int aio_read(struct aiocb *aiocbp); issues an asynchronous read request
  - int aio_error(const struct aiocb *aiocbp); checks whether the request (designated by the aiocb) has completed
  - Checking IO completion is inefficient, perhaps we need interrupt-based approaches (e.g. UNIX signals) to inform applications when async IO completes.
- Problems
  - State management
    - manual stack management: when an event handler issues an asynchronous I/O, it must package up some ==program state for the next event handler== to use when the I/O finally completes; this additional work is ==not needed in thread-based programs==, as the state the program needs is on the stack of the thread. hl-page:: 438 ls-type:: annotation id:: 6436a3d9-ee29-4378-af79-4efc770cc209 hl-color:: yellow
    - continuation: record the needed information to finish processing this event in some data structure; when the event happens (i.e., when the disk I/O completes), look up the needed information and process the event. hl-page:: 440 ls-type:: annotation id:: 6436a40a-121f-4fab-b428-b278e4cb65d3 hl-color:: yellow
  - Utilizing multiple CPUs hl-page:: 440 ls-type:: annotation id:: 6436a46c-f845-4c7b-8bb1-97da71589c67 hl-color:: yellow
  - Implicit blocking such as paging hl-page:: 440 ls-type:: annotation id:: 6436a485-7a70-4974-93d2-9e11b010a948 hl-color:: yellow
  - Messy code base due to complicated asynchronous logic
obstinate 固执的；棘手的；难以去除的； hl-page:: 448 ls-type:: annotation id:: 6436ca1f-f4e7-431e-9620-be7764825acd hl-color:: green
pickle 泡菜；腌菜 ls-type:: annotation hl-page:: 448 hl-color:: green id:: 6436caa1-6fe0-4de8-9ad4-2a057960fc1a
System Architecture ls-type:: annotation hl-page:: 450 hl-color:: yellow id:: 6436cc2e-b1af-4555-9d1d-808e6de120b1

35 KiB Raw Blame History Unescape Escape

Part II

thread

Locks

Lock-based Concurrent Data Structures

condition variable

Semaphores

Deadlock

Event-based Concurrency

35 KiB

Raw Blame History