22mckenney_rcu

22mckenney_rcu - Read-Copy Update Using Execution History...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
1 Read-Copy Update: Using Execution History to Solve Concurrency Problems P.E. McKenney, Senior Member, IEEE , and J.D. Slingwine Abstract— The problems of synchronization overhead, contention, and deadlock can pose serious challenges to those designing and implementing parallel programs. Therefore, many researchers have proposed parallel update disciplines that greatly reduce these problems in restricted but commonly occurring situations, for example, read-mostly data structures [7, 10, 11, 13, 18]. However, these proposals rely either on garbage collectors [10, 11], termination of all processes currently using the data structure [13], or expensive explicit tracking of all processes accessing the data structure [7, 18]. These mechanisms are inappropriate in many cases, such as within many operating-system kernels and server applications. This paper proposes a novel and extremely efficient mechanism, called read-copy update, and compares its performance to that of conventional locking primitives under conditions of both low and high contention in read-intensive data structures. Index Terms —Shared memory, mutual exclusion, reader-writer locking, performance, contention. 1 Introduction Reducing lock contention and synchronization overhead will continue to be important in parallel design and implementation because increases in CPU- core instruction-execution rate are expected to continue to outstrip reductions in global latency for large-scale multiprocessors [3, 6, 22]. This trend will cause global lock and synchronization operations to continue becoming more costly relative to instructions that manipulate local data. Expensive global lock operations are particularly troublesome when the locks are used to guard read-mostly data structures. In this common special case, reading processes pay a heavy penalty to guard against very rare events. To see how rare these events can be, consider the following two examples. The first example is a routing table for a system connected to the Internet. Many Internet routing protocols process routing changes at most every minute or so. Therefore, a system transmitting at the low rate of 100 packets per second would need to perform a routing-table update at most once per 6,000 packets, for an update fraction f of less than 10 -3 . The second example is a system with 100 mirrored disks, each of which has an MTBF
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
2 of 100,000 hours. 1 A transaction-processing system performing 10,000 disk I/Os per second would perform in excess of 10 10 I/Os on the average before having to update the internal tables tracking which disk contains which data. This yields a value below 10 -10 for f . Both these examples demonstrate the performance benefits to be gained by decreasing the overhead incurred by reading threads and CPUs, even at the cost of great increases in that incurred by writing CPUs and threads. These examples motivate specialized locking designs that make fewer read-side references to globally shared, often- updated variables.
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}

Page1 / 28

22mckenney_rcu - Read-Copy Update Using Execution History...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online