SLIDE 1
The basic problem
- Operating systems need concurrency
- Operating systems need shared data structures
Practical Concerns for Scalable Synchronization Josh Triplett May - - PowerPoint PPT Presentation
Practical Concerns for Scalable Synchronization Josh Triplett May - - PowerPoint PPT Presentation
Practical Concerns for Scalable Synchronization Josh Triplett May 10, 2006 The basic problem Operating systems need concurrency Operating systems need shared data structures The basic problem Operating systems need concurrency
SLIDE 2
SLIDE 3
The basic problem
- Operating systems need concurrency
- Operating systems need shared data structures
SLIDE 4
Mutual exclusion?
- Readers and writers acquire a lock
- Doesn’t scale
- High contention
- Priority inversion
- Deadlock
SLIDE 5
Mutual exclusion?
- Readers and writers acquire a lock
- Doesn’t scale
- High contention
- Priority inversion
- Deadlock
SLIDE 6
Mutual exclusion?
- Readers and writers acquire a lock
- Doesn’t scale
- High contention
- Priority inversion
- Deadlock
SLIDE 7
Mutual exclusion?
- Readers and writers acquire a lock
- Doesn’t scale
- High contention
- Priority inversion
- Deadlock
SLIDE 8
Mutual exclusion?
- Readers and writers acquire a lock
- Doesn’t scale
- High contention
- Priority inversion
- Deadlock
SLIDE 9
Speed up contended case
- Better spin locks
- Queuing locks
- How much does the high-contention case matter?
SLIDE 10
Speed up contended case
- Better spin locks
- Queuing locks
- How much does the high-contention case matter?
SLIDE 11
Speed up contended case
- Better spin locks
- Queuing locks
- How much does the high-contention case matter?
SLIDE 12
Reduce contention
- Contention-reducing data structures (two-lock queue)
- Reader-writer locking
- Localizing data to avoid sharing or false sharing
SLIDE 13
Reduce contention
- Contention-reducing data structures (two-lock queue)
- Reader-writer locking
- Localizing data to avoid sharing or false sharing
SLIDE 14
Reduce contention
- Contention-reducing data structures (two-lock queue)
- Reader-writer locking
- Localizing data to avoid sharing or false sharing
SLIDE 15
Contention less relevant
- Atomic instructions expensive
- Memory barriers expensive
- 3 orders of magnitude worse than regular instruction
- For locking, lock maintenance time dominates
- For non-blocking synchronization, CAS or LL/SC time
dominates
SLIDE 16
Contention less relevant
- Atomic instructions expensive
- Memory barriers expensive
- 3 orders of magnitude worse than regular instruction
- For locking, lock maintenance time dominates
- For non-blocking synchronization, CAS or LL/SC time
dominates
SLIDE 17
Contention less relevant
- Atomic instructions expensive
- Memory barriers expensive
- 3 orders of magnitude worse than regular instruction
- For locking, lock maintenance time dominates
- For non-blocking synchronization, CAS or LL/SC time
dominates
SLIDE 18
Contention less relevant
- Atomic instructions expensive
- Memory barriers expensive
- 3 orders of magnitude worse than regular instruction
- For locking, lock maintenance time dominates
- For non-blocking synchronization, CAS or LL/SC time
dominates
SLIDE 19
Contention less relevant
- Atomic instructions expensive
- Memory barriers expensive
- 3 orders of magnitude worse than regular instruction
- For locking, lock maintenance time dominates
- For non-blocking synchronization, CAS or LL/SC time
dominates
SLIDE 20
Avoiding expensive instructions
- Writer needs locking or non-blocking synchronization
- What about the reader?
- Need to ensure that the reader won’t crash
- Crashes caused by following a bad pointer
- Assignment to an aligned pointer happens atomically
- Insert and remove items atomically
- Need some memory barriers: prevent insertion before
initialization
SLIDE 21
Avoiding expensive instructions
- Writer needs locking or non-blocking synchronization
- What about the reader?
- Need to ensure that the reader won’t crash
- Crashes caused by following a bad pointer
- Assignment to an aligned pointer happens atomically
- Insert and remove items atomically
- Need some memory barriers: prevent insertion before
initialization
SLIDE 22
Avoiding expensive instructions
- Writer needs locking or non-blocking synchronization
- What about the reader?
- Need to ensure that the reader won’t crash
- Crashes caused by following a bad pointer
- Assignment to an aligned pointer happens atomically
- Insert and remove items atomically
- Need some memory barriers: prevent insertion before
initialization
SLIDE 23
Avoiding expensive instructions
- Writer needs locking or non-blocking synchronization
- What about the reader?
- Need to ensure that the reader won’t crash
- Crashes caused by following a bad pointer
- Assignment to an aligned pointer happens atomically
- Insert and remove items atomically
- Need some memory barriers: prevent insertion before
initialization
SLIDE 24
Avoiding expensive instructions
- Writer needs locking or non-blocking synchronization
- What about the reader?
- Need to ensure that the reader won’t crash
- Crashes caused by following a bad pointer
- Assignment to an aligned pointer happens atomically
- Insert and remove items atomically
- Need some memory barriers: prevent insertion before
initialization
SLIDE 25
Avoiding expensive instructions
- Writer needs locking or non-blocking synchronization
- What about the reader?
- Need to ensure that the reader won’t crash
- Crashes caused by following a bad pointer
- Assignment to an aligned pointer happens atomically
- Insert and remove items atomically
- Need some memory barriers: prevent insertion before
initialization
SLIDE 26
Avoiding expensive instructions
- Writer needs locking or non-blocking synchronization
- What about the reader?
- Need to ensure that the reader won’t crash
- Crashes caused by following a bad pointer
- Assignment to an aligned pointer happens atomically
- Insert and remove items atomically
- Need some memory barriers: prevent insertion before
initialization
SLIDE 27
Reclamation
- What about reclamation?
- Can remove item atomically: reader sees structure with or
without
- Can’t free item immediately:
- What if memory reused, reader interprets new data as pointer
to item?
- Segmentation fault:
core dumped
- (Best case scenario)
SLIDE 28
Reclamation
- What about reclamation?
- Can remove item atomically: reader sees structure with or
without
- Can’t free item immediately:
- What if memory reused, reader interprets new data as pointer
to item?
- Segmentation fault:
core dumped
- (Best case scenario)
SLIDE 29
Reclamation
- What about reclamation?
- Can remove item atomically: reader sees structure with or
without
- Can’t free item immediately:
- What if memory reused, reader interprets new data as pointer
to item?
- Segmentation fault:
core dumped
- (Best case scenario)
SLIDE 30
Reclamation
- What about reclamation?
- Can remove item atomically: reader sees structure with or
without
- Can’t free item immediately:
- What if memory reused, reader interprets new data as pointer
to item?
- Segmentation fault:
core dumped
- (Best case scenario)
SLIDE 31
Reclamation
- What about reclamation?
- Can remove item atomically: reader sees structure with or
without
- Can’t free item immediately:
- What if memory reused, reader interprets new data as pointer
to item?
- Segmentation fault:
core dumped
- (Best case scenario)
SLIDE 32
Reclamation
- What about reclamation?
- Can remove item atomically: reader sees structure with or
without
- Can’t free item immediately:
- What if memory reused, reader interprets new data as pointer
to item?
- Segmentation fault:
core dumped
- (Best case scenario)
SLIDE 33
Deferred reclamation
- Insertion fine anytime
- Removal fine anytime, but. . .
- Can’t reclaim an item out from under a reader
- Removal prevents new readers
- How to know current readers stopped using it?
SLIDE 34
Deferred reclamation
- Insertion fine anytime
- Removal fine anytime, but. . .
- Can’t reclaim an item out from under a reader
- Removal prevents new readers
- How to know current readers stopped using it?
SLIDE 35
Deferred reclamation
- Insertion fine anytime
- Removal fine anytime, but. . .
- Can’t reclaim an item out from under a reader
- Removal prevents new readers
- How to know current readers stopped using it?
SLIDE 36
Deferred reclamation
- Insertion fine anytime
- Removal fine anytime, but. . .
- Can’t reclaim an item out from under a reader
- Removal prevents new readers
- How to know current readers stopped using it?
SLIDE 37
Deferred reclamation
- Insertion fine anytime
- Removal fine anytime, but. . .
- Can’t reclaim an item out from under a reader
- Removal prevents new readers
- How to know current readers stopped using it?
SLIDE 38
Deferred reclamation procedure
- Remove item from structure, making it inaccessible to new
readers
- Wait for all old readers to finish
- Free the old item
- Note: only synchronizes between readers and reclaimers, not
writers
- Complements other synchronization
SLIDE 39
Deferred reclamation procedure
- Remove item from structure, making it inaccessible to new
readers
- Wait for all old readers to finish
- Free the old item
- Note: only synchronizes between readers and reclaimers, not
writers
- Complements other synchronization
SLIDE 40
Deferred reclamation procedure
- Remove item from structure, making it inaccessible to new
readers
- Wait for all old readers to finish
- Free the old item
- Note: only synchronizes between readers and reclaimers, not
writers
- Complements other synchronization
SLIDE 41
Deferred reclamation procedure
- Remove item from structure, making it inaccessible to new
readers
- Wait for all old readers to finish
- Free the old item
- Note: only synchronizes between readers and reclaimers, not
writers
- Complements other synchronization
SLIDE 42
Deferred reclamation procedure
- Remove item from structure, making it inaccessible to new
readers
- Wait for all old readers to finish
- Free the old item
- Note: only synchronizes between readers and reclaimers, not
writers
- Complements other synchronization
SLIDE 43
Epochs
- Maintain per-thread and global epochs
- Reads and writes associated with an epoch
- When all threads have passed an epoch, free items removed in
previous epochs
- Reader needs atomic instructions, memory barriers
SLIDE 44
Epochs
- Maintain per-thread and global epochs
- Reads and writes associated with an epoch
- When all threads have passed an epoch, free items removed in
previous epochs
- Reader needs atomic instructions, memory barriers
SLIDE 45
Epochs
- Maintain per-thread and global epochs
- Reads and writes associated with an epoch
- When all threads have passed an epoch, free items removed in
previous epochs
- Reader needs atomic instructions, memory barriers
SLIDE 46
Epochs
- Maintain per-thread and global epochs
- Reads and writes associated with an epoch
- When all threads have passed an epoch, free items removed in
previous epochs
- Reader needs atomic instructions, memory barriers
SLIDE 47
Hazard pointers
- Readers mark items in use with hazard pointers
- Writers check for removed items in all hazard pointers before
freeing.
- Reader still needs atomic instructions, memory barriers
SLIDE 48
Hazard pointers
- Readers mark items in use with hazard pointers
- Writers check for removed items in all hazard pointers before
freeing.
- Reader still needs atomic instructions, memory barriers
SLIDE 49
Hazard pointers
- Readers mark items in use with hazard pointers
- Writers check for removed items in all hazard pointers before
freeing.
- Reader still needs atomic instructions, memory barriers
SLIDE 50
Problem: reader efficiency
- Epochs and hazard pointers have expensive read sides
- Readers must also write
- Readers must use atomic instructions
- Readers must use memory barriers
- Can we know readers have finished as an external observer?
SLIDE 51
Problem: reader efficiency
- Epochs and hazard pointers have expensive read sides
- Readers must also write
- Readers must use atomic instructions
- Readers must use memory barriers
- Can we know readers have finished as an external observer?
SLIDE 52
Problem: reader efficiency
- Epochs and hazard pointers have expensive read sides
- Readers must also write
- Readers must use atomic instructions
- Readers must use memory barriers
- Can we know readers have finished as an external observer?
SLIDE 53
Problem: reader efficiency
- Epochs and hazard pointers have expensive read sides
- Readers must also write
- Readers must use atomic instructions
- Readers must use memory barriers
- Can we know readers have finished as an external observer?
SLIDE 54
Problem: reader efficiency
- Epochs and hazard pointers have expensive read sides
- Readers must also write
- Readers must use atomic instructions
- Readers must use memory barriers
- Can we know readers have finished as an external observer?
SLIDE 55
Quiescent-state-based reclamation
- Define quiescent states for threads
- Threads cannot hold item references in a quiescent state
- Let “grace periods” contain a quiescent state for every thread
- Wait for one grace period; every thread passes through a
quiescent state
- No readers could hold old references, new references can’t see
removed item
SLIDE 56
Quiescent-state-based reclamation
- Define quiescent states for threads
- Threads cannot hold item references in a quiescent state
- Let “grace periods” contain a quiescent state for every thread
- Wait for one grace period; every thread passes through a
quiescent state
- No readers could hold old references, new references can’t see
removed item
SLIDE 57
Quiescent-state-based reclamation
- Define quiescent states for threads
- Threads cannot hold item references in a quiescent state
- Let “grace periods” contain a quiescent state for every thread
- Wait for one grace period; every thread passes through a
quiescent state
- No readers could hold old references, new references can’t see
removed item
SLIDE 58
Quiescent-state-based reclamation
- Define quiescent states for threads
- Threads cannot hold item references in a quiescent state
- Let “grace periods” contain a quiescent state for every thread
- Wait for one grace period; every thread passes through a
quiescent state
- No readers could hold old references, new references can’t see
removed item
SLIDE 59
Quiescent-state-based reclamation
- Define quiescent states for threads
- Threads cannot hold item references in a quiescent state
- Let “grace periods” contain a quiescent state for every thread
- Wait for one grace period; every thread passes through a
quiescent state
- No readers could hold old references, new references can’t see
removed item
SLIDE 60
Read Copy Update (RCU)
- Read-side critical sections
- Items don’t disappear inside critical section
- Quiescent states outside critical section
- Writers must guarantee reader correctness at every point
- In theory: copy entire data structure, replace pointer
- In practice: insert or remove items atomically
- Writers defer reclamation by waiting for read-side critical
sections
- Writers may block and reclaim, or register a reclamation
callback
SLIDE 61
Read Copy Update (RCU)
- Read-side critical sections
- Items don’t disappear inside critical section
- Quiescent states outside critical section
- Writers must guarantee reader correctness at every point
- In theory: copy entire data structure, replace pointer
- In practice: insert or remove items atomically
- Writers defer reclamation by waiting for read-side critical
sections
- Writers may block and reclaim, or register a reclamation
callback
SLIDE 62
Read Copy Update (RCU)
- Read-side critical sections
- Items don’t disappear inside critical section
- Quiescent states outside critical section
- Writers must guarantee reader correctness at every point
- In theory: copy entire data structure, replace pointer
- In practice: insert or remove items atomically
- Writers defer reclamation by waiting for read-side critical
sections
- Writers may block and reclaim, or register a reclamation
callback
SLIDE 63
Read Copy Update (RCU)
- Read-side critical sections
- Items don’t disappear inside critical section
- Quiescent states outside critical section
- Writers must guarantee reader correctness at every point
- In theory: copy entire data structure, replace pointer
- In practice: insert or remove items atomically
- Writers defer reclamation by waiting for read-side critical
sections
- Writers may block and reclaim, or register a reclamation
callback
SLIDE 64
Read Copy Update (RCU)
- Read-side critical sections
- Items don’t disappear inside critical section
- Quiescent states outside critical section
- Writers must guarantee reader correctness at every point
- In theory: copy entire data structure, replace pointer
- In practice: insert or remove items atomically
- Writers defer reclamation by waiting for read-side critical
sections
- Writers may block and reclaim, or register a reclamation
callback
SLIDE 65
Read Copy Update (RCU)
- Read-side critical sections
- Items don’t disappear inside critical section
- Quiescent states outside critical section
- Writers must guarantee reader correctness at every point
- In theory: copy entire data structure, replace pointer
- In practice: insert or remove items atomically
- Writers defer reclamation by waiting for read-side critical
sections
- Writers may block and reclaim, or register a reclamation
callback
SLIDE 66
Read Copy Update (RCU)
- Read-side critical sections
- Items don’t disappear inside critical section
- Quiescent states outside critical section
- Writers must guarantee reader correctness at every point
- In theory: copy entire data structure, replace pointer
- In practice: insert or remove items atomically
- Writers defer reclamation by waiting for read-side critical
sections
- Writers may block and reclaim, or register a reclamation
callback
SLIDE 67
Read Copy Update (RCU)
- Read-side critical sections
- Items don’t disappear inside critical section
- Quiescent states outside critical section
- Writers must guarantee reader correctness at every point
- In theory: copy entire data structure, replace pointer
- In practice: insert or remove items atomically
- Writers defer reclamation by waiting for read-side critical
sections
- Writers may block and reclaim, or register a reclamation
callback
SLIDE 68
Classic RCU
- Read lock: disable preemption
- Read unlock: enable preemption
- Quiescent state: context switch
- Scheduler flags quiescent states
- Readers perform no expensive operations
SLIDE 69
Classic RCU
- Read lock: disable preemption
- Read unlock: enable preemption
- Quiescent state: context switch
- Scheduler flags quiescent states
- Readers perform no expensive operations
SLIDE 70
Classic RCU
- Read lock: disable preemption
- Read unlock: enable preemption
- Quiescent state: context switch
- Scheduler flags quiescent states
- Readers perform no expensive operations
SLIDE 71
Classic RCU
- Read lock: disable preemption
- Read unlock: enable preemption
- Quiescent state: context switch
- Scheduler flags quiescent states
- Readers perform no expensive operations
SLIDE 72
Classic RCU
- Read lock: disable preemption
- Read unlock: enable preemption
- Quiescent state: context switch
- Scheduler flags quiescent states
- Readers perform no expensive operations
SLIDE 73
Realtime RCU
- Quiescent states tracked by per-CPU counters
- read lock, read unlock: manipulate counters
- Readers perform no expensive operations
- Allows preemption in critical sections
- Less efficient than classic RCU
SLIDE 74
Realtime RCU
- Quiescent states tracked by per-CPU counters
- read lock, read unlock: manipulate counters
- Readers perform no expensive operations
- Allows preemption in critical sections
- Less efficient than classic RCU
SLIDE 75
Realtime RCU
- Quiescent states tracked by per-CPU counters
- read lock, read unlock: manipulate counters
- Readers perform no expensive operations
- Allows preemption in critical sections
- Less efficient than classic RCU
SLIDE 76
Realtime RCU
- Quiescent states tracked by per-CPU counters
- read lock, read unlock: manipulate counters
- Readers perform no expensive operations
- Allows preemption in critical sections
- Less efficient than classic RCU
SLIDE 77
Realtime RCU
- Quiescent states tracked by per-CPU counters
- read lock, read unlock: manipulate counters
- Readers perform no expensive operations
- Allows preemption in critical sections
- Less efficient than classic RCU
SLIDE 78
Read-mostly structures
- RCU ideal for read-mostly structures
- Permissions
- Hardware configuration data
- Routing tables and firewall rules
SLIDE 79
Read-mostly structures
- RCU ideal for read-mostly structures
- Permissions
- Hardware configuration data
- Routing tables and firewall rules
SLIDE 80
Read-mostly structures
- RCU ideal for read-mostly structures
- Permissions
- Hardware configuration data
- Routing tables and firewall rules
SLIDE 81
Read-mostly structures
- RCU ideal for read-mostly structures
- Permissions
- Hardware configuration data
- Routing tables and firewall rules
SLIDE 82
Synchronizing between updates
- RCU doesn’t solve this
- Need separate synchronization to coordinate updates
- Can build on non-blocking synchronization or locking
- Many non-blocking algorithms don’t account for reclamation
at all
- Can add RCU to avoid memory leaks
- Reclamation strategry mostly orthogonal from update strategy
SLIDE 83
Synchronizing between updates
- RCU doesn’t solve this
- Need separate synchronization to coordinate updates
- Can build on non-blocking synchronization or locking
- Many non-blocking algorithms don’t account for reclamation
at all
- Can add RCU to avoid memory leaks
- Reclamation strategry mostly orthogonal from update strategy
SLIDE 84
Synchronizing between updates
- RCU doesn’t solve this
- Need separate synchronization to coordinate updates
- Can build on non-blocking synchronization or locking
- Many non-blocking algorithms don’t account for reclamation
at all
- Can add RCU to avoid memory leaks
- Reclamation strategry mostly orthogonal from update strategy
SLIDE 85
Synchronizing between updates
- RCU doesn’t solve this
- Need separate synchronization to coordinate updates
- Can build on non-blocking synchronization or locking
- Many non-blocking algorithms don’t account for reclamation
at all
- Can add RCU to avoid memory leaks
- Reclamation strategry mostly orthogonal from update strategy
SLIDE 86
Synchronizing between updates
- RCU doesn’t solve this
- Need separate synchronization to coordinate updates
- Can build on non-blocking synchronization or locking
- Many non-blocking algorithms don’t account for reclamation
at all
- Can add RCU to avoid memory leaks
- Reclamation strategry mostly orthogonal from update strategy
SLIDE 87
Synchronizing between updates
- RCU doesn’t solve this
- Need separate synchronization to coordinate updates
- Can build on non-blocking synchronization or locking
- Many non-blocking algorithms don’t account for reclamation
at all
- Can add RCU to avoid memory leaks
- Reclamation strategry mostly orthogonal from update strategy
SLIDE 88
Memory consistency model
- Handles non-sequentially-consistent memory
- Minimal memory barriers
- Does not provide sequential consistency
- Provides weaker consistency model
- Readers may see writes in any order
- Readers cannot see an inconsistent intermediate state
- Does not provide linearizability
- Many algorithms do not require these guarantees
SLIDE 89
Memory consistency model
- Handles non-sequentially-consistent memory
- Minimal memory barriers
- Does not provide sequential consistency
- Provides weaker consistency model
- Readers may see writes in any order
- Readers cannot see an inconsistent intermediate state
- Does not provide linearizability
- Many algorithms do not require these guarantees
SLIDE 90
Memory consistency model
- Handles non-sequentially-consistent memory
- Minimal memory barriers
- Does not provide sequential consistency
- Provides weaker consistency model
- Readers may see writes in any order
- Readers cannot see an inconsistent intermediate state
- Does not provide linearizability
- Many algorithms do not require these guarantees
SLIDE 91
Memory consistency model
- Handles non-sequentially-consistent memory
- Minimal memory barriers
- Does not provide sequential consistency
- Provides weaker consistency model
- Readers may see writes in any order
- Readers cannot see an inconsistent intermediate state
- Does not provide linearizability
- Many algorithms do not require these guarantees
SLIDE 92
Memory consistency model
- Handles non-sequentially-consistent memory
- Minimal memory barriers
- Does not provide sequential consistency
- Provides weaker consistency model
- Readers may see writes in any order
- Readers cannot see an inconsistent intermediate state
- Does not provide linearizability
- Many algorithms do not require these guarantees
SLIDE 93
Memory consistency model
- Handles non-sequentially-consistent memory
- Minimal memory barriers
- Does not provide sequential consistency
- Provides weaker consistency model
- Readers may see writes in any order
- Readers cannot see an inconsistent intermediate state
- Does not provide linearizability
- Many algorithms do not require these guarantees
SLIDE 94
Memory consistency model
- Handles non-sequentially-consistent memory
- Minimal memory barriers
- Does not provide sequential consistency
- Provides weaker consistency model
- Readers may see writes in any order
- Readers cannot see an inconsistent intermediate state
- Does not provide linearizability
- Many algorithms do not require these guarantees
SLIDE 95
Memory consistency model
- Handles non-sequentially-consistent memory
- Minimal memory barriers
- Does not provide sequential consistency
- Provides weaker consistency model
- Readers may see writes in any order
- Readers cannot see an inconsistent intermediate state
- Does not provide linearizability
- Many algorithms do not require these guarantees
SLIDE 96
Performance testing
- Tested RCU and hazard pointers, with locking or NBS
- All better than locking
- RCU variants: near-ideal performance
- Best performer for low write fractions
- Highly competitive for higher write fractions
SLIDE 97
Performance testing
- Tested RCU and hazard pointers, with locking or NBS
- All better than locking
- RCU variants: near-ideal performance
- Best performer for low write fractions
- Highly competitive for higher write fractions
SLIDE 98
Performance testing
- Tested RCU and hazard pointers, with locking or NBS
- All better than locking
- RCU variants: near-ideal performance
- Best performer for low write fractions
- Highly competitive for higher write fractions
SLIDE 99
Performance testing
- Tested RCU and hazard pointers, with locking or NBS
- All better than locking
- RCU variants: near-ideal performance
- Best performer for low write fractions
- Highly competitive for higher write fractions
SLIDE 100
Performance testing
- Tested RCU and hazard pointers, with locking or NBS
- All better than locking
- RCU variants: near-ideal performance
- Best performer for low write fractions
- Highly competitive for higher write fractions
SLIDE 101
Conclusion
- RCU implements quiescent-state-based deferred reclamation
- No expensive overhead for readers
- Minimally expensive overhead for writers
- Ideal for read-mostly situations
SLIDE 102
Conclusion
- RCU implements quiescent-state-based deferred reclamation
- No expensive overhead for readers
- Minimally expensive overhead for writers
- Ideal for read-mostly situations
SLIDE 103
Conclusion
- RCU implements quiescent-state-based deferred reclamation
- No expensive overhead for readers
- Minimally expensive overhead for writers
- Ideal for read-mostly situations
SLIDE 104
Conclusion
- RCU implements quiescent-state-based deferred reclamation
- No expensive overhead for readers
- Minimally expensive overhead for writers
- Ideal for read-mostly situations