diff --git a/.idea/.gitignore b/.idea/.gitignore
new file mode 100644
index 0000000..30cf57e
--- /dev/null
+++ b/.idea/.gitignore
@@ -0,0 +1,10 @@
+# Default ignored files
+/shelf/
+/workspace.xml
+# Editor-based HTTP Client requests
+/httpRequests/
+# Ignored default folder with query files
+/queries/
+# Datasource local storage ignored files
+/dataSources/
+/dataSources.local.xml
diff --git a/.idea/compiler.xml b/.idea/compiler.xml
new file mode 100644
index 0000000..812c3f9
--- /dev/null
+++ b/.idea/compiler.xml
@@ -0,0 +1,13 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/.idea/encodings.xml b/.idea/encodings.xml
new file mode 100644
index 0000000..aa00ffa
--- /dev/null
+++ b/.idea/encodings.xml
@@ -0,0 +1,7 @@
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/.idea/jarRepositories.xml b/.idea/jarRepositories.xml
new file mode 100644
index 0000000..4158879
--- /dev/null
+++ b/.idea/jarRepositories.xml
@@ -0,0 +1,20 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/.idea/misc.xml b/.idea/misc.xml
new file mode 100644
index 0000000..b1ee00f
--- /dev/null
+++ b/.idea/misc.xml
@@ -0,0 +1,12 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/.idea/vcs.xml b/.idea/vcs.xml
new file mode 100644
index 0000000..35eb1dd
--- /dev/null
+++ b/.idea/vcs.xml
@@ -0,0 +1,6 @@
+
+
+
+
+
+
\ No newline at end of file
diff --git a/Answer.md b/Answer.md
new file mode 100644
index 0000000..405c726
--- /dev/null
+++ b/Answer.md
@@ -0,0 +1,266 @@
+# Atomic Variables & Synchronization
+
+## 1. What are Atomic Variables?
+
+Atomic variables are variables that allow operations to be performed in a single, indivisible step. This means that while one thread is performing an atomic operation, another thread cannot interrupt it or see an incomplete result.
+
+The main reason we use atomic variables is to safely handle shared data in multithreaded programs without always depending on locks. They help prevent race conditions, where multiple threads try to update the same value at the same time and produce incorrect results.
+
+### Common Uses of Atomic Variables
+
+Atomic variables are commonly used for:
+
+* Maintaining counters shared between multiple threads
+* Updating status flags safely
+* Building lock-free or low-lock algorithms
+* Managing communication between threads
+
+### Atomic vs Non-Atomic Variables
+
+| Atomic Variables | Ordinary Variables |
+| ---------------------------------------------------------- | ------------------------------------------------------ |
+| Operations are completed as one indivisible step. | Operations can be interrupted by other threads. |
+| Safe for multiple threads to access at the same time. | Can cause race conditions when accessed concurrently. |
+| Provide memory visibility and ordering guarantees. | Do not provide thread synchronization. |
+| May have some performance overhead due to synchronization. | Usually faster because no synchronization is involved. |
+
+### Example
+
+A normal increment operation is not actually a single operation:
+
+```cpp
+counter++;
+```
+
+It is performed in three steps:
+
+1. Read the current value
+2. Increase the value
+3. Write the new value back
+
+If two threads perform this operation at the same time, both threads may read the same value and overwrite each other's updates. This can cause some increments to be lost.
+
+Using an atomic variable solves this problem:
+
+```cpp
+std::atomic counter(0);
+counter++;
+```
+
+The increment happens safely because the entire operation is treated as one atomic action.
+
+Atomic variables are useful when we need fast and thread-safe updates to individual variables.
+
+---
+
+# 2. Classes in `java.util.concurrent.atomic`
+
+Java provides the `java.util.concurrent.atomic` package for performing thread-safe operations without manually using locks.
+
+Some commonly used atomic classes are:
+
+* `AtomicInteger` - Works with integer values
+* `AtomicLong` - Works with long values
+* `AtomicBoolean` - Works with boolean values
+* `AtomicReference` - Works with object references
+
+Other classes include:
+
+* `AtomicIntegerArray`
+* `AtomicLongArray`
+* `AtomicReferenceArray`
+* `AtomicStampedReference`
+* `AtomicMarkableReference`
+
+### Example: Using AtomicInteger
+
+A common example is maintaining a counter that multiple threads update at the same time.
+
+```java
+import java.util.concurrent.atomic.AtomicInteger;
+
+AtomicInteger requestCount = new AtomicInteger(0);
+
+requestCount.incrementAndGet();
+```
+
+Methods like `incrementAndGet()` and `getAndIncrement()` allow threads to safely update the counter without requiring synchronization using locks.
+
+For example, a web server can use an `AtomicInteger` to count the number of requests processed by different threads. Each thread can update the counter safely, and the final value will remain accurate.
+
+---
+
+# 3. Atomic Variables vs Locks
+
+Both atomic variables and locks are used for thread synchronization, but they solve different problems.
+
+| Atomic Variables | Locks |
+| ---------------------------------------------------------------------- | --------------------------------------------------------------- |
+| Used for simple operations like incrementing or updating one variable. | Used for protecting larger sections of code. |
+| Usually faster because they avoid blocking. | Can have more overhead due to locking and waiting. |
+| Good for single-variable updates. | Better for complex operations involving multiple variables. |
+| Support lock-free programming. | Allow only one thread to execute a protected section at a time. |
+| Cannot easily handle multiple related operations together. | Can make a group of operations execute safely as one unit. |
+
+### When to Use Atomic Variables
+
+Atomic variables are useful when:
+
+* Only one variable needs to be updated safely.
+* The operation is simple, such as incrementing a counter.
+* Performance is important.
+* We want to avoid unnecessary locking.
+
+Example:
+
+Using `AtomicInteger` to count requests handled by multiple threads.
+
+### When to Use Locks
+
+Locks are better when:
+
+* Multiple variables need to be updated together.
+* Several operations must happen as one atomic action.
+* Shared data structures like lists, maps, or queues need protection.
+* The logic is more complex.
+
+Example:
+
+A bank transfer requires updating two account balances. Both accounts must be updated together, so a lock is needed to prevent another thread from accessing them during the transfer.
+
+In simple terms:
+
+* Use atomic variables for fast, simple, thread-safe updates.
+* Use locks when multiple operations or resources need to be protected together.
+
+---
+
+# Why Race-Free Programs Can Still Perform Poorly
+
+A program can be free from race conditions and still have poor performance under heavy load. Correct synchronization does not always mean good scalability.
+
+Several factors can limit performance:
+
+## 1. Lock Contention
+
+Even if locks are used correctly, they can become a performance problem when many threads try to acquire the same lock.
+
+Only one thread can enter the critical section at a time, while other threads must wait. As the number of threads increases, more time is spent waiting instead of doing useful work.
+
+## 2. Limited Parallelism Due to Shared Resources
+
+A program may be thread-safe but still depend on shared resources such as:
+
+* Databases
+* Files
+* Memory structures
+* Network connections
+
+If many threads need the same resource, they must wait for each other. Adding more threads may not improve performance and can sometimes make it worse.
+
+## 3. Synchronization Overhead
+
+Synchronization mechanisms like locks, semaphores, barriers, and atomic operations have a cost.
+
+Threads may spend time:
+
+* Waiting for other threads
+* Acquiring and releasing locks
+* Coordinating their work
+
+In highly concurrent systems, this overhead can reduce the benefits of using multiple threads.
+
+### Other Factors Affecting Scalability
+
+* **Context switching:** The CPU spends time switching between threads instead of executing useful work.
+* **Cache contention and false sharing:** Threads updating nearby memory locations can cause cache synchronization problems.
+* **Load imbalance:** Some threads may finish early while others still have a lot of work.
+
+A program can be logically correct and race-free but still fail to scale because of resource competition, synchronization costs, and hardware limitations.
+
+---
+
+# Why More Threads Do Not Always Improve Performance
+
+Adding more threads does not always make a program faster. Threads introduce additional overhead, and after a certain point, the cost of managing them can become greater than the benefit of parallel execution.
+
+## 1. Context Switching
+
+When there are more threads than available CPU cores, the operating system must switch between threads.
+
+During a context switch, the CPU saves the current thread's state and loads another thread's state. This process takes time and does not directly contribute to completing the actual task.
+
+Too many threads can cause the system to spend more time managing threads than doing useful work.
+
+## 2. Competition for Shared Resources
+
+Threads often need access to common resources like:
+
+* Memory
+* Files
+* Databases
+* Shared data structures
+
+When many threads access the same resource, they must wait for each other. This reduces the amount of actual parallel work being performed.
+
+## 3. Cache Coherence Overhead
+
+Modern processors have multiple cores with their own caches.
+
+When different threads modify shared data, the processor must keep the caches synchronized. Frequent updates can cause cache invalidation and additional memory transfers between cores.
+
+This increases delays and reduces performance.
+
+## 4. Synchronization Overhead
+
+Concurrency tools such as locks, mutexes, semaphores, and atomic operations help prevent race conditions, but they also add overhead.
+
+Threads may spend time waiting for locks or coordinating with each other. Under heavy load, synchronization can become a major bottleneck.
+
+Increasing the number of threads helps only when there is enough independent work and available resources. Beyond that point, overhead from context switching, resource contention, cache updates, and synchronization can reduce performance.
+
+---
+
+# Why Deadlocks Usually Appear in Production
+
+Deadlocks are often difficult to reproduce during testing because thread scheduling is unpredictable.
+
+The order in which threads run, acquire locks, and release resources depends on many factors, including:
+
+* System load
+* CPU availability
+* Timing
+* Hardware differences
+
+A deadlock happens when two or more threads wait forever for resources held by each other.
+
+Example:
+
+* Thread A locks Resource 1 and waits for Resource 2.
+* Thread B locks Resource 2 and waits for Resource 1.
+
+Both threads are waiting, so neither can continue.
+
+During testing, the threads may execute in a different order, so the deadlock may never happen. In production, higher traffic and more concurrent users increase the chance of the problematic timing occurring.
+
+## Ways to Find Deadlocks During Testing
+
+### 1. Stress Testing with High Concurrency
+
+Developers can run many threads and create heavy workloads similar to production.
+
+More concurrent activity increases the chance of finding timing-related problems and lock-order issues.
+
+### 2. Control Thread Timing
+
+Developers can intentionally slow down execution at important points by:
+
+* Adding delays
+* Using debugging tools
+* Using concurrency testing frameworks
+
+For example, pausing a thread after it acquires one lock but before it acquires another can make a deadlock easier to reproduce.
+
+Testing different thread execution orders can help reveal hidden synchronization problems.
+
+In conclusion, deadlocks are difficult to detect because they depend on specific timing conditions. Increasing concurrency and controlling thread execution during testing can help discover these problems before they happen in production.
diff --git a/src/main/java/dev/banking/model/BankAccount.java b/src/main/java/dev/banking/model/BankAccount.java
index 745ede2..afb5aaa 100644
--- a/src/main/java/dev/banking/model/BankAccount.java
+++ b/src/main/java/dev/banking/model/BankAccount.java
@@ -1,18 +1,12 @@
package dev.banking.model;
+import java.util.concurrent.locks.ReentrantLock;
+
public class BankAccount {
private final int accountId;
- private long balance;
-
- /*
- * Students may introduce additional fields
- * such as:
- * - Lock / ReentrantLock
- * - ReadWriteLock
- * - Object monitor
- * - etc.
- */
+ private volatile long balance;
+ private final ReentrantLock lock = new ReentrantLock();
public BankAccount(int accountId, long initialBalance) {
this.accountId = accountId;
@@ -23,56 +17,51 @@ public class BankAccount {
return accountId;
}
- /*
- * TODO:
- * Return the current balance in a thread-safe way.
- *
- * Requirements:
- * - Must be safe under concurrent reads/writes
- * - Should not block unnecessarily if using read/write locks
- */
+
public long getBalance() {
- throw new UnsupportedOperationException("TODO: implement thread-safe balance read");
+ return balance;
}
- /*
- * TODO:
- * Increase balance atomically.
- *
- * Requirements:
- * - Must not lose updates under concurrency
- */
+
public void deposit(long amount) {
- throw new UnsupportedOperationException("TODO: implement thread-safe deposit");
+ lock.lock();
+ try {
+ balance += amount;
+ } finally {
+ lock.unlock();
+ }
}
- /*
- * TODO:
- * Decrease balance atomically.
- *
- * Requirements:
- * - Must not cause race conditions
- * - Negative balance handling is NOT required unless you decide
- * to extend the system (optional)
- */
public void withdraw(long amount) {
- throw new UnsupportedOperationException("TODO: implement thread-safe withdraw");
+ lock.lock();
+ try {
+ balance -= amount;
+ } finally {
+ lock.unlock();
+ }
}
- /*
- * TODO:
- * Transfer money between two accounts atomically.
- *
- * IMPORTANT REQUIREMENTS:
- * - Must be atomic (no partial transfer)
- * - Must be deadlock-free
- * - Must protect both source and target accounts
- *
- * HINT:
- * - Consider global lock ordering using accountId
- * - Or tryLock with retry strategy
- */
+
public void transfer(BankAccount target, long amount) {
- throw new UnsupportedOperationException("TODO: implement atomic deadlock-free transfer");
+
+ if (this == target) {
+ return; // transferring to itself is a no-op
+ }
+
+ BankAccount first = this.accountId < target.accountId ? this : target;
+ BankAccount second = this.accountId < target.accountId ? target : this;
+
+ first.lock.lock();
+ try {
+ second.lock.lock();
+ try {
+ this.balance -= amount;
+ target.balance += amount;
+ } finally {
+ second.lock.unlock();
+ }
+ } finally {
+ first.lock.unlock();
+ }
}
-}
\ No newline at end of file
+}