This strategy effectively defines a conceptual

Info icon This preview shows pages 3–5. Sign up to view the full content.

View Full Document Right Arrow Icon
This strategy effectively defines a conceptual partial order on locks and requires that a thread tries to acquire a lock only if all locks currently held by the thread (if any) come earlier in the partial order. It is merely a programming convention that the entire program must get right. To understand how this ordering idea can be useful, we return to our transferTo ex- ample. Suppose we wanted transferTo to be atomic. A simpler way to write the code that still has the deadlock problem we started with is: void transferTo ( int amt, BankAccount a) { synchronized ( this ) { synchronized (a) { this . withdraw (amt); a. deposit (amt); } } } Here we make explicit that we need the locks guarding both accounts and we hold those locks throughout the critical section. This version is easier to understand and the po- CPEN 221 – Fall 2016
Image of page 3

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

View Full Document Right Arrow Icon
Deadlocks 4 tential deadlock — still caused by another thread performing a transfer to the accounts in reverse order — is also more apparent. (Note in passing that a deadlock involving more threads is also possible. For example, thread 1 could transfer from A to B, thread 2 from B to C, and thread 3 from C to A.) The critical section has two locks to acquire. If all threads acquired these locks in the same order, then no deadlock could occur. In our deadlock example where one thread calls x.transferTo(1,y) and the other calls y.transferTo(1,x) , this is exactly what goes wrong: one acquires x} before y} and the other y before x . We want one of the threads to acquire the locks in the other order. In general, there is no clear way to do this, but sometimes our data structures have some unique identifier that lets us pick an arbitrary order to prevent deadlock. Suppose, as is the case in actual banks, that every BankAccount already has an acctNumber field of type int that is distinct from every other acctNumber . Then we can use these numbers to require that threads always acquire locks for bank accounts in increasing order. (We could also require decreasing order, the key is that all code agrees on one way or the other.) We can then write transferTo like this: class BankAccount { ... private int acctNumber; // must be unique void transferTo ( int amt, BankAccount a) { if ( this . acctNumber < a. acctNumber ) synchronized ( this ) { synchronized (a) { this . withdraw (amt); a. deposit (amt); } } else synchronized (a) { synchronized ( this ) { this . withdraw (amt); a. deposit (amt); } } } } While it may not be obvious that this code prevents deadlock, it should be obvious that CPEN 221 – Fall 2016
Image of page 4
Image of page 5
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