Add Book to My BookshelfPurchase This Book Online

Chapter 3 - Synchronizing Pthreads

Pthreads Programming
Bradford Nichols, Dick Buttlar and Jacqueline Proulx Farrell
 Copyright © 1996 O'Reilly & Associates, Inc.

Chapter 3: Synchronizing Pthreads
Overview
Creating threads is the easy part. It's harder to get them to share data properly. We're tempted to make the obvious analogy to children. To prevent damage to the Nintendo (and the children), we'll only let the one who folds the laundry that evening play Donkey Kong. Similarly, to make threads share data safely, we must ensure that threads that would otherwise behave independently access shared data in an orderly and controlled way. This concept is called synchronization.(The other concept is called good parenting.)
Sooner or later, you'll probably make a programming error and fail to synchronize threads. It would be nice if you could get a feel for the symptoms of synchronization failures so that you can react quickly and expertly to such a disaster. Unfortunately, as we'll see, almost any type of quirky behavior might be regarded as a symptom of a synchronization failure. Worse, you may see problems only every so often when you run your program; at other times, if the threads in the program just happen to access data in the right order in a particular run, the program may run fine. So you may notice incorrect output at random times—perhaps in one run out of a hundred. In fact, this come-and-go quality of errors may be the best indicator that your bug is in the way in which you've handled thread synchronization.
Let's suppose we forgot to include synchronization in the ATM server we created in Chapter 2, Designing Threaded Programs. When one of our imaginary bank's customers deposits money in an account, she expects that, ultimately, her account balance will be its original value plus the amount she deposited. She probably can't even conceive of anything our bank could do to interfere with her transaction and cause her end balance to be any different than she expects. In other words, she assumes that her deposit is a single, indivisible transaction (if she were a software engineer, she'd know that the word for that type of transaction is atomic)that occurs in isolation from other transactions. It's anything but. Her deposit may consist of many, many separate tasks: disk reads, memory reads, calculations, data modifications, memory writes, disk writes, and more. Worse, without synchronization in our ATM server, we'll allow a similar transaction to preempt her deposit at any step—before all of the steps required to make it a deposit have completed.
But it's likely she'll have no problems until, for instance, she tries to withdraw $50 from her account at the same time her husband across town also tries to withdraw $50. This type of problem is known as a race condition. A race condition is illustrated in Figure 3-1.
Figure 3-1: ATM race condition with two withdraw threads
In a race condition, two or more threads access the same resource at the same time. In Figure 3-1, Thread 1 and Thread 2 simultaneously attempt a withdrawal from the same bank account. Thread1 reads the current balance of the account—$125. However, before it can proceed with the other steps that complete the withdrawal (the arithmetic, the storing of the new result, and the dispensing of cash), it is preempted by Thread 2. Thread 2 also reads the account balance—$125, but Thread 2 continues on to complete the transaction. It subtracts $50 from$125, stores the new balance, $75, in the account database, and hands the customer a $50 bill. Sometime thereafter, Thread 1 resumes, subtracts $50from $125 (which is what it thinks is the account balance), stores the new balance, $75, in the account database, and hands the other customer a$50 bill. Nothing looks wrong to either thread, but in actuality, we've allowed one thread to clobber the write of another. We've subtracted a total of $100 from $125 and have come up with $75. A bank could lose a lot of money if this was allowed to happen.*
 *Actually, the error just happened to be in the customer's favor because the operations were both withdrawals. If the operations were deposits, the error would be in the bank's favor.
The problem with our ATM server is that the three key steps in the withdraw transaction—the reading of the balance, the calculation of the new balance, and the storing of the new balance in the account database—should be atomic. Either all of the steps are performed together without interruption, or none of them are.

Previous SectionNext Section
Books24x7.com, Inc © 2000 –  Feedback