Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Apply Critical Sections Consistently Example 1: One Producer, Many Consumers, Using Locks Example 2: One Producer, Many Consumers, Using Lock-Free Mailboxes Example 3: Don't Try to Turn Critical Sections Inside Out

The critical section is our One True Tool for guaranteeing mutual exclusion on mutable shared variables. Table 1 summarizes several common ways to express exclusive critical sections (see last month's column [1] for details). A useful way to think about the synchronization in your program is as a daisy-chain of these "release-acquire" handoffs that stitch all the threads' critical sections together into some linear order, so that each one "acquires" the cumulative work done and is "released" by all the others that preceded it.

Like most tools, these must be applied consistently, and with the intended meanings. A program must ensure that every use of a mutable shared object is properly protected using exactly one of these mechanisms at any given point in its lifetime. Chaos can erupt if code tries to avoid or invert these meanings (e.g., trying to abuse taking a lock or reading an atomic variable as a "critical section exit" operation; see Example 3), or tries to use inconsistent synchronization techniques at the same time.

Let's consider some examples to illustrate the proper and improper uses of critical sections, to get us used to looking for where the critical sections' synchronization points should appear in the code.

1 Apply Critical Sections Consistently | 2 Example 1: One Producer, Many Consumers, Using Locks | 3 Example 2: One Producer, Many Consumers, Using Lock-Free Mailboxes | 4 Example 3: Don't Try to Turn Critical Sections Inside Out Next Page

RELATED ARTICLES Multitouch Gains Momentum ASP.NET Gets Testable Adobe, Saleforce.com Team Up for Flash Builder for Force.com Other Voices: 8 IT Predictions for 2010 Fuzzing Security Testing Tool Released		TOP 5 ARTICLES No Top Articles.