In this example one thread transfers from one account

Info icon This preview shows pages 2–4. Sign up to view the full content.

View Full Document Right Arrow Icon
In this example, one thread transfers from one account (call it “A”) to another (call it “B”) while the other thread transfers from B to A. With just the wrong interleaving, the first thread holds the lock for A and is blocked on the lock for B while the second thread holds the lock for B and is blocked on the lock for A. So both are waiting for a lock to be released by a thread that is blocked. They will wait forever. More generally, a deadlock occurs when there are threads T 1 , T 2 , ..., T n such that: 1. For 1 i ( n - 1 ) , T i is waiting for a resource held by T i + 1 2. T n is waiting for a resource held by T 1 In other words, there is a cycle of waiting. 2 Avoiding Deadlocks Now that we have seen an example that results in a deadlock, we should consider meth- ods to avoid deadlocks. Returning to our example, there is, unfortunately, no obvious way to write an atomic transferTo method that will not deadlock. Depending on our needs we could write: CPEN 221 – Fall 2016
Image of page 2

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

View Full Document Right Arrow Icon
Deadlocks 3 void transferTo ( int amt, BankAccount a) { this . withdraw (amt); a. deposit (amt); } All we have done is make transferTo not be synchronized. Because withdraw and deposit are still synchronized methods, the only negative effect is that an intermedi- ate state is potentially exposed: Another thread that retrieved the balances of the two accounts in the transfer could now “see” the state where the withdraw had occurred but not the deposit. If that is okay in our application, then this is a sufficient solution. If not, another approach would be to resort to coarse-grained locking where all accounts use the same lock. Either of these approaches avoids deadlock because they ensure that no thread ever holds more than one lock at a time. This is a sufficient but not necessary condition for avoiding deadlock because it cannot lead to a cycle of waiting. A much more flexible sufficient-but-not-necessary strategy that subsumes the often-unworkable “only one lock at a time strategy” works as follows: For all pairs of locks x and y , either do not have a thread ever (try to) hold both x and y simultaneously or have a globally agreed upon order, meaning either x is always acquired before y or y is always acquired before x .
Image of page 3
Image of page 4
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}

What students are saying

  • Left Quote Icon

    As a current student on this bumpy collegiate pathway, I stumbled upon Course Hero, where I can find study resources for nearly all my courses, get online help from tutors 24/7, and even share my old projects, papers, and lecture notes with other students.

    Student Picture

    Kiran Temple University Fox School of Business ‘17, Course Hero Intern

  • Left Quote Icon

    I cannot even describe how much Course Hero helped me this summer. It’s truly become something I can always rely on and help me. In the end, I was not only able to survive summer classes, but I was able to thrive thanks to Course Hero.

    Student Picture

    Dana University of Pennsylvania ‘17, Course Hero Intern

  • Left Quote Icon

    The ability to access any university’s resources through Course Hero proved invaluable in my case. I was behind on Tulane coursework and actually used UCLA’s materials to help me move forward and get everything together on time.

    Student Picture

    Jill Tulane University ‘16, Course Hero Intern