As we have seen, the key challenge in concurrent programming is to manage the accesses by concurrent threads to shared resources. And we've learned about using locks in different kinds of ways to do that. We will now learn about a higher level construct called a critical section, that's also referred to as an isolated construct. So, let me share with you an example from my personal life. I have a bank account. And my bank account has, let's say $500. My family has a joint bank account which is shared with the family and my daughter. And that has $1000. And my daughter, who's in college, has her own bank account. And she's in college, so the balance is $0. So, she texts me and says that she needs more money, and the way we get her more money is that I have to transfer $100 to her by putting $100 in the family account. And then, she gets $100 from the family account transferred to her. Now, we can model this operation using two threads. So, there's a thread T1, where I will have to deduct 100 from my balance and add 100 to the family balance. And my daughter's action can be modeled by thread T2, where she will deduct 100 from the family balance. And add, to her balance, $100. These days, the money just keeps flowing from parent to children. Now, the question is, what can go wrong if this were to be executed as a parallel program? Well, we've seen this kind of scenario before. And to look at this a little more closely, we see that there's this shared variable "family" that is read and written by the two threads. And the ordering of read and write accesses to this shared variable can cause issues. So, let me refer to the read and write in thread T1 as R1, W1. And the read and write as R2, W2. Now, let us consider what can happen when this is executed in parallel the way it is written. These reads and writes can be interleaved in any order, and let us consider one order. Let's suppose the read R2 happened, then the read R1, then the write W2, then the write W1. What this means is that my daughter would first read R2 and compute the family balance as 900. Then, I would read R1 and compute this sum as 1100. My daughter's thread would then write W2, which would update family to 900. And I would then write W1 which should update family to 1100. So, what would happen is that my balance would go from 500 to 400, which is what is accepted. And my daughter's balance would go from 0 to 100. But family would first get the value 900, then the value 1100. And 1100 is wrong. I mean, we would be happy with that because we would have made a $100, but that's not what is intended to happen. So, the way to avoid this, as we know, is by using locks. But this is a frequent enough situation that we need a higher level construct. And that's referred to as a critical section. And so there we will use the notation isolated to indicate that these two blocks of code have to be executed in mutual exclusion. How that mutual exclusion is engineered is not the programmer's problem. It could be implemented using locks. It could be implemented using some new hardware features like transactional memory. But we've raised our level of concurrent programming now. Instead of doing acquire lock, release lock, or synchronize, we've just said isolated. These two cannot be interleaved. The program should see the effect of one isolated section completely before it starts another, though the two could go in any order. So, with isolated, the possible orderings would be R2, but then if this isolated section started, W2 has to complete. And then we can have R1, W1. Or the other possible ordering would be this, my isolated goals first, so we have R1 W1. And then, my daughter's isolated, which is R2 W2. If you work it out, you'll see in both cases, you'll get the final outcome that we want, which is 400, 1,000, 100. Which would be the correct answer after you do the appropriate transfers. So, what we've seen is that concurrent programming can be challenging. And though locks are one way to manage access to shared resources, they are lower level constructs. And these critical sections using the isolated notation are a very convenient way of guaranteeing mutual exclusion and avoiding these risk conditions and erroneous answers.