Critical Section Problem
Critical section refers to a segment of code that is executed by multiple concurrent threads or processes, and which accesses shared resources. These resources may include shared memory, files, or other system resources that can only be accessed by one thread or process at a time to avoid data inconsistency or race conditions. In other words, when more than one processes try to access the same code segment that segment is known as the critical section.
- For example, imagine you are using an online banking system, where you can perform various tasks like transferring money, checking your account balance, and paying bills. Now, consider that many users are accessing their bank accounts at the same time.
- The system must ensure that every user's transactions are processed accurately and without any interference from other users. In this system, each user represents a process. For example, when you log in to transfer money, your session is one process. At the same time, other users are also logged in and performing their own transactions, each represented by their own processes.
- The critical section in this context is the part of the code where the bank updates the account balance. For example, when you transfer $100 to someone, the system checks your balance, deducts $100, and then updates your account with the new balance.
- Suppose two users, User A, and User B, both have access to the same joint bank account, which has a balance of $200. If User A and User B both try to transfer $100 out of the account at the exact same time, here's what could go wrong:
- User A’s process checks the balance (sees $200) and decides to deduct $100. Simultaneously, User B’s process also checks the balance (also sees $200) and decides to deduct $100. Both processes think there's enough money and proceed to make the deduction. However, both processes might update the balance separately, each thinking the balance is now $100. The final result could be that the bank account shows $100, but actually, $200 was deducted, which means $100 disappeared due to the incorrect handling of simultaneous access. This is an example of race condition where the outcome depends on the unpredictable timing of processes, which can happen if multiple processes enter the critical section simultaneously.
- To prevent this, the operating system ensures that when one person (process) is accessing the critical section (the part of the code handling the balance), no one else can access it at the same time. This is done using synchronization mechanisms like locks or semaphores.
The main requirements for solving the critical section problem are often referred to as the Critical Section Design Criteria:
- Mutual Exclusion: Only one process can be in the critical section at any given time.
- Progress: If no process is in the critical section and there are processes that wish to enter, then one of the waiting processes should be allowed to enter the critical section.
- Bounded Waiting: A process should not have to wait indefinitely to enter the critical section. There must be a limit on the number of times other processes are allowed to enter the critical section before the waiting process gets its turn.

Good job
ReplyDelete