Friday, 17 May 2024

Quick overview on Race condition in Application Development

In today's computer world, things often happen at the same time. When multiple operations occur simultaneously, they can clash and create a problem called a race condition. This happens in programming when two operations compete to be done first.

 

Let me explain with an example:

Imagine we have a shared variable called 'counter'. Several threads are tasked with increasing this counter whenever they execute a job to keep track of how many tasks they've completed.

 

1.   Thread 1 gets a task to execute.

2.   Thread 2 also gets a task to execute.

3.   Both threads check the counter. It's at 0.

4.   Thread 1 adds 1 to the counter and saves it back (now it's 1).

5.   Thread 2 does the same, adding 1 to the counter (now it's 1 again).

 


Here's the problem: Both threads read the counter at 0, then add 1 to it, unaware of each other. So, even though each thread thinks it's updated the counter to 1, the actual value is 2.

 

To prevent this, we need to ensure threads don't interfere with each other when accessing shared resources like the counter. We can use techniques like locks or atomic operations to coordinate their actions and avoid race conditions.

 

Following are some ways to avoid race condition.

 

1. Immutable Data structures

Using immutable data structures can help avoid race conditions. These structures have values that can't be changed once they're created. So, even multiple threads access them, race condition problem will not occur.

When you use immutable data structures, you're essentially saying, "Hey, here's this piece of data, and it's never going to change." Because the data can't change, there's no risk of one thread trying to modify it while another thread is also using it. This eliminates the need for synchronization mechanisms like locks or mutexes, which can slow down your program and make it more complex.

 

So, by opting for immutable data structures, you're not just simplifying your code, you're also making it safer and more efficient in multithreaded environments.

 

2. Go with Thread safe data structures

There are certain thread safe data structures like AtomicInteger, ConcurrentHashMap provide thread-safe operations without requiring external synchronization. They're designed specifically for scenarios where multiple threads need to access shared data concurrently, making them effective tools for avoiding race conditions and ensuring thread safety in Java applications.

 

3. Use Synchronizaiton techniques

Synchronization is a common way to manage threads. With synchronization, we use tools like locks and semaphores to make sure thatonly one thread can use a shared thing at once. This stops problems and keeps our data reliable.

 

Mutex (Mutual Exclusion): Imaging a single-occupancy restroom in a busy public place, like a mall. The restroom door has a lock that allows only one person inside at a time. When someone enters and locks the door, others have to wait until the person finishes and unlocks the door before they can use the restroom. This ensures that only one person can use the restroom at any given time, preventing awkward situations and maintaining privacy. Similarly, a mutex in programming ensures exclusive access to a shared resource, allowing only one thread to use it at a time and avoiding conflicts or data corruption.

 

Semaphore: Consider a library study room with limited seating. The room has a capacity for a certain number of students to study comfortably. A semaphore acts like the librarian managing access to the room. When students arrive, they check with the librarian to see if there's space available. If the room is full, the librarian tells them to wait until someone leaves. Once there's an empty seat, the librarian allows another student to enter. Similarly, a semaphore in programming controls access to a shared resource by limiting the number of threads that can use it simultaneously, ensuring efficient resource utilization and preventing overcrowding.


                                                                                System Design Questions

No comments:

Post a Comment