161110-SharedMemoryConcurrency.pdf

If one call happens to finish before the other starts

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

View Full Document Right Arrow Icon
• If one call happens to finish before the other starts, then the behavior is like in a sequential program. This is like one cook using a pot and then another cook using the same pot. When this is not the case, we say the calls interleave . Note that interleaving can happen even with one processor because a thread can be pre-empted at any point, meaning the thread scheduler stops the thread and runs another one. CPEN 221 – Fall 2016
Image of page 4

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

View Full Document Right Arrow Icon
Basic Shared-Memory Concurrency 5 So let us consider two interleaved calls to withdraw on the same bank account. We will “draw” interleavings using a vertical timeline (earlier operations closer to the top) with each thread in a separate column. There are many possible interleavings since even the operations in a helper method like getBalance can be interleaved with operations in other threads. But here is one incorrect interleaving. Assume initially the balance field holds 150 and both withdrawals are passed 100. Remember that each thread exe- cutes a different method call with its own “local” variables b and amount but the calls to getBalance and setBalance are, we assume, reading/writing the one balance field of the same object. Thread 1 Thread 2 -------- -------- int b = getBalance(); int b = getBalance(); if(amount > b) throw new ...; setBalance(b - amount); // sets balance to 50 if(amount > b) // no exception: b holds 150 throw new ...; setBalance(b - amount); If this interleaving occurs, the resulting balance will be 50 and no exception will be thrown. But two withdraw operations were supposed to occur — there should be an exception. Somehow we “lost” a withdraw, which would not make the bank happy. The problem is that balance changed after Thread 1 retrieved it and stored it in b . When first learning concurrent programming there is a natural but almost-always wrong attempted fix to this sort of problem. It is tempting to rearrange or repeat operations to try to avoid using “stale” information like the value in b . Here is a wrong idea : void withdraw(int amount) { if(amount > getBalance()) throw new WithdrawTooLargeException(); // maybe balance changed, so get the new balance setBalance(getBalance() - amount); } The idea above is to call getBalance() a second time to get any updated val- ues. But there is still the potential for an incorrect interleaving. Just because CPEN 221 – Fall 2016
Image of page 5
Basic Shared-Memory Concurrency 6 setBalance(getBalance() - amount) is on one line in our source code does not mean it happens all at once. This code still (a) calls getBalance , then (b) subtracts amount from the result, then (c) calls setBalance . Moreover (a) and (c) may consist of multiple steps. In any case, the balance can change between (a) and (c), so we have not really accomplished anything except we might now produce a negative balance without raising an exception. The sane way to fix this sort of problem, which arises whenever we have concurrent access to shared memory that might change (i.e., the contents are mutable ), is to enforce mutual exclusion : allow only one thread to access any particular account at a time.
Image of page 6

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

View Full Document Right Arrow Icon
Image of page 7
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