Migrate development environment from Windows to macOS and continue project updates

- Shifted primary development environment from Windows to macOS to ensure better performance, stability, and streamlined workflow for Java development.
- Removed OS-specific metadata and ensured platform-agnostic project compatibility.
- Normalized line endings to LF for cross-platform consistency.
- Verified and adjusted file paths, permissions, and encoding settings to suit macOS environment.
- Cleaned up unnecessary Windows-generated files and updated Git configuration accordingly.
- Future commits and development will now be
managed entirely from macOS.

This migration ensures a cleaner, more consistent
setup moving forward and prepares the project for
scalable development across Unix-based systems.

Future development will continue on macOS for a
smoother, Unix-based experience.

Signed-off-by: Someshdiwan <[email protected]>

Author: Someshdiwan

out/production/DeadLock/DeadLock.class

@@ -0,0 +1,68 @@
+It is a situation in multi-threading where two or more threads
+are blocked forever waiting for each other to release a resources.
+
+This typically occurs when two or more threads have circular dependencies on a set of locks.
+necessary conditions for a deadlock to occur in a system:
+
+Mutual Exclusion: A resource can only be used by one thread/process at a time.
+Hold and Wait: A thread holding a resource is waiting for another resource held by another thread.
+No Preemption: A resource cannot be forcibly taken away from a thread holding it.
+Circular Wait: A circular chain of two or more threads exists, where each thread waits for a resource held by the next.
+
+Deadlock Prevention, Detection, and Resolution
+
+1. Deadlock Prevention:
+
+To prevent deadlocks, we must eliminate at least one of the four necessary conditions.
+
+  - Breaking Mutual Exclusion
+  - Make resources shareable whenever possible.
+  - Example: Read-only files can be accessed by multiple processes.
+
+  - Breaking Hold and Wait
+  - Require a process to request all required resources at once (resource allocation in a single request).
+  - Example: Database transactions acquire all locks before proceeding.
+
+  - Breaking No Preemption
+  - Allow resources to be preempted (taken away) from a process if needed.
+  - Example: CPU scheduling can forcefully remove a process from execution.
+
+  - Breaking Circular Wait
+  - Impose an **ordering on resource requests** (number resources and require them to be requested in increasing order).
+  - Example: If a process holds Resource 1, it must request Resource 2 before Resource 3.
+
+
+2. Deadlock Detection:
+
+If prevention is not feasible, we use detection mechanisms:
+
+  - Resource Allocation Graph (RAG)
+  - Used for single-instance resource systems. A cycle in the graph indicates a deadlock.
+
+  - Wait-for Graph
+  - Derived from RAG by removing resource nodes. A cycle in this graph confirms a deadlock.
+
+  - Detection Algorithm (Banker's Algorithm for Deadlock Detection)
+  - Periodically checks for circular dependencies in multi-instance resource systems.
+
+---
+
+3. Deadlock Resolution (Recovery):
+
+Once a deadlock is detected, recovery strategies include:
+
+  - Process Termination**
+  - Kill one or more processes involved in the deadlock.
+  - Either terminate all deadlocked processes or terminate one at a time until deadlock is resolved.
+
+  - Resource Preemption
+  - Take resources from some processes and reallocate them.
+  - Requires rollback mechanisms to avoid inconsistencies.
+
+---
+
+Choosing the Right Strategy:
+
+- Prevention is best if system design allows.
+- Detection & Recovery are necessary in dynamic systems like OS and databases.
+- Avoidance (Banker’s Algorithm) is used when processes declare maximum resource needs in advance.

out/production/DeadLock/DeadLocks

@@ -0,0 +1,86 @@
+Deep Dive into Thread Safety Techniques
+
+Now, let’s break down three key techniques used to ensure thread safety in real-world applications:
+
+1. Database Transactions & ACID Properties
+2. Locking Mechanisms (Synchronized, ReentrantLock, Distributed Locks)
+3. Atomic Operations (Atomic Variables & Compare-and-Swap - CAS)
+
+---
+
+1. Database Transactions & ACID Properties:
+
+Problem: Race Condition in a Banking System:
+
+Imagine two people withdrawing money from the same account at the exact same time.
+
+- User A wants to withdraw $500
+- User B wants to withdraw $600
+- The initial balance is $1000, so both requests think they have enough funds.
+- If the system is not thread-safe, it may allow both transactions to happen, making the balance negative (-$100).
+
+Solution: ACID Transactions in Databases:
+
+ACID (Atomicity, Consistency, Isolation, Durability) ensures that transactions are processed safely.
+
+- Atomicity: The transaction is all or nothing. If one step fails, everything rolls back.
+- Consistency: The database remains in a valid state before and after a transaction.
+- Isolation: No two transactions interfere with each other.
+- Durability: Once committed, data is permanently stored, even in case of a crash.
+
+Real-world Example: If you’ve ever had a failed online payment and saw 
+"Transaction Reversed," that’s Atomicity in action!
+
+---
+
+2. Locking Mechanisms (Preventing Deadlocks & Race Conditions):
+
+Types of Locks:
+
+1. Synchronized Locks (Java's synchronized keyword):
+
+   - Ensures only one thread can execute a method at a time.
+   - Example: If a user is editing a shared document, another user must wait before making changes.
+
+2. ReentrantLock (More Flexible than `synchronized`):
+   - Allows fine-grained control over locks, including timeouts and fairness policies.
+   - Example: Uber ensures that only one person can book a driver at a time using a lock.
+
+3. Distributed Locks (Used in Cloud Applications):
+   - Used when multiple servers are involved (e.g., Google Docs, Uber, Banking).
+   - Redis-based locks, Zookeeper locks, and AWS DynamoDB locks ensure global thread safety across multiple servers.
+
+
+Real-world Example: When two people try to book the last ticket, one gets it, and the other sees "Seat Unavailable". 
+That's locking in action!
+
+---
+
+3. Atomic Operations & Compare-and-Swap (CAS):
+
+Problem: Incrementing a Shared Counter in Multi-threaded Systems
+
+Imagine you have a website tracking visitor count using a shared variable.
+
+- If 1000 users visit at the same time, they might **all read the same old value**, causing **wrong counts**.
+
+Solution: Atomic Variables (Thread-Safe Counters):
+
+Instead of using normal integers, we use atomic variables like `AtomicInteger` (Java) or CAS operations.
+
+- Atomic operations ensure that a value is updated safely, without explicit locks.
+- Compare-and-Swap (CAS) is a low-level operation that compares the old value and updates 
+it only if it hasn’t changed (ensuring no race conditions).
+
+Real-world Example: Websites like YouTube, Facebook, and Twitter use atomic counters to 
+accurately track likes, views, and shares!
+
+---
+
+Key Takeaways for Interviews
+1. ACID Transactions → Used in banking, stock trading, and online payments to ensure correctness.
+2. Locking Mechanisms** → Used in Uber, Google Docs, and ticket booking systems to prevent double bookings.
+3. Atomic Operations & CAS → Used in **social media platforms (likes, shares, views) and 
+distributed systems for high-speed counters.
+
+deadlocks, optimistic locking, or distributed locking techniques? 🚀

out/production/DeadLock/Deep Dive into Thread Safety Techniques

@@ -0,0 +1,68 @@
+Detailed Real-World Examples of Thread Safety:
+
+I'll break down **two critical real-world scenarios where thread safety plays a major role, along with solutions.
+
+1. Online Banking System - Preventing Race Conditions:
+
+Scenario:
+
+Imagine a bank account where two users (threads) are trying to withdraw money at the same time.
+
+- Account Balance: $1000
+- User 1 (Thread A) wants to withdraw: $800
+- User 2 (Thread B) wants to withdraw: $500
+
+- Both threads check the balance at the same time (before the transaction is processed).
+- Each sees $1000 and believes there is enough money.
+- Both transactions proceed, and the total withdrawal is $1300, even though only $1000 was available.
+- Final balance becomes negative (-$300), which should not be possible!
+
+What Went Wrong?
+- This is a race condition where multiple threads are accessing and modifying shared data without synchronization.
+- The balance check and update should be done atomically (as a single operation).
+
+Solution
+- Use synchronization to ensure that only one withdrawal happens at a time.
+- Use atomic variables (like AtomicInteger in Java) to ensure thread-safe balance updates.
+- Implement database transactions to lock the balance during the withdrawal process.
+
+📌 Real-world example: If you've ever seen a failed transaction message like "Insufficient Funds",
+it means the banking system is handling this properly.
+
+2. Ticket Booking System - Avoiding Double Booking**
+
+Scenario: Imagine an online movie ticket booking system where two users are trying to book the last available seat
+at the same time.
+
+- User 1 (Thread A) selects the seat at 10:00:05 AM
+- User 2 (Thread B) selects the same seat at 10:00:06 AM
+
+- If the system is not thread-safe, both users might be assigned the same seat.
+- When they arrive at the theater, both have the same seat number, causing a conflict.
+
+What Went Wrong?
+
+- The system is checking seat availability without properly locking it, leading to double booking.
+- The seat allocation is not an atomic operation (it checks and updates separately).
+
+Solution:
+
+1. Use Thread-Safe Collections
+   - Use a ConcurrentHashMap or synchronized list to manage available seats.
+
+2. Locking Mechanism
+   - When a seat is selected, lock it until payment is completed.
+
+3. Database Transactions
+   - Use ACID-compliant transactions in the database to ensure that once a seat is booked,
+    it cannot be selected by another user.
+
+📌 Real-world example: If you've ever seen "Seat already booked, please select another" in a booking app,
+that's the system handling concurrency properly.
+
+
+Key Takeaways:
+
+- Thread safety prevents critical real-world issues like double booking and financial errors.
+- Race conditions happen when multiple threads modify shared data simultaneously.
+- Using synchronization, atomic variables, and database transactions can prevent these issues.

out/production/DeadLock/Detailed Real-World Examples of Thread Safety

@@ -0,0 +1,66 @@
+More Real-World Examples of Thread Safety with Deep Explanations:
+
+Now, let’s dive into two more complex and real-world scenarios where thread safety is crucial.
+
+
+3. Cloud Document Editing – Avoiding Inconsistent Updates (Google Docs Example)
+
+Scenario
+Imagine multiple users are editing the same Google Docs file in real time.
+
+- User 1 (Thread A) edits Line 5 and changes "Hello" to "Hi".
+- User 2 (Thread B) edits Line 5 at the same time and changes "Hello" to "Hey".
+- If both changes happen simultaneously **without synchronization, the document 
+could end up with an inconsistent state (one user’s edit might overwrite another’s).
+
+What Went Wrong?
+- Both users fetched the old text before updating it, leading to data loss when one update overwrites the other.
+- This is called a **lost update problem**, a common issue in multi-user collaborative editing.
+
+Solution
+1. Operational Transformation (OT) or Conflict-Free Replicated Data Types (CRDTs)
+   - Google Docs and similar tools use OT or CRDTs to merge changes in real time.
+   - Instead of overwriting, it **tracks individual changes and intelligently merges them**.
+
+2. Locking Mechanism for Critical Sections
+   - Some document editing tools lock sections of a document so only one user can edit a specific line at a time.
+
+3. Version Control with Timestamps
+   - Every edit is assigned a timestamp and version number to track which change should be applied first.
+
+📌 Real-world example: In Google Docs, when two people edit the same word, both edits are preserved intelligently 
+instead of getting lost.
+
+4. Ride-Sharing App (Uber) – Handling Concurrent Ride Requests**
+
+Scenario
+Imagine a ride-sharing app like Uber, where multiple riders request the same nearby driver at the same time.
+
+- User 1 (Thread A) books Driver X at 10:00:10 AM.
+- User 2 (Thread B) also books Driver X at 10:00:11 AM.
+- If the system is not thread-safe, both users may be assigned the same driver, leading to booking conflicts.
+
+What Went Wrong?
+- Multiple requests were processed simultaneously, leading to the same driver being booked twice.
+- There was no synchronization on driver availability before confirming the ride.
+
+Solution:
+1. Atomic Database Transactions
+   - When a ride request is made, the database **locks the driver** entry until the booking is confirmed.
+
+2. Distributed Locking Mechanism
+   - Uber uses a distributed lock system** across multiple servers to ensure **only one rider gets a driver** at a time.
+
+3. Queue-Based Processing
+   - Instead of handling all ride requests at once, they queue ride requests and process them one by one.
+
+📌 Real-world example: Have you ever tried booking an Uber and seen Driver Unavailable even though you 
+just clicked? That’s the system ensuring thread safety to prevent double bookings.
+
+
+-- Key Takeaways for Interviews
+-  Thread safety is critical in cloud-based applications, ride-sharing, and banking systems.
+-  Techniques like Operational Transformation (OT), database transactions, and distributed locks prevent data inconsistencies.
+-  Real-world services like Google Docs, Uber, and banking apps use sophisticated thread safety techniques to avoid issues.
+
+deep dive into any specific technique, such as database transactions, locking mechanisms, or atomic operations* 🚀

out/production/DeadLock/More Real-World Examples of Thread Safety with Deep Explanations

@@ -0,0 +1,50 @@
+Real-World Examples of Thread Safety:
+
+1. Online Banking System (Race Condition Example)
+
+Imagine two users trying to withdraw money from the same bank account at the same time:
+
+Thread 1: Withdraws $500 from an account with $1000.
+
+Thread 2: Withdraws $600 at the same time.
+
+If both transactions read the balance simultaneously, they might both think there is enough money, leading to an
+overdrawn account.
+
+Solution: The banking system must ensure that only one transaction is processed at a time using thread-safe mechanisms
+like synchronization or atomic transactions.
+
+2. Ticket Booking System (Thread-safe Collections)
+
+Suppose multiple users are trying to book the last available seat in a theater at the same time.
+
+If the system is not thread-safe, two users might end up booking the same seat, causing a double booking.
+
+Solution: The ticketing system can use thread-safe data structures like a concurrent queue or synchronized database
+transactions to prevent such conflicts.
+
+3. Shared File Editing (Deadlock Scenario)
+
+Imagine two users editing the same file in a cloud-based application.
+Thread A locks the file and tries to access the metadata.
+Thread B locks the metadata and tries to access the file.
+
+Both threads are waiting for each other to release their locks, leading to a deadlock, where neither can proceed.
+
+Solution: A proper locking strategy (e.g., acquiring locks in a predefined order) ensures that deadlocks don’t happen.
+
+4. E-Commerce Website (Thread-safe Counters)
+
+During a flash sale, thousands of users are adding products to their carts.
+
+If a non-thread-safe counter is used to track the available stock, multiple users might be shown the same last product,
+leading to overselling.
+
+Solution: Using atomic operations ensures that each stock update is correctly processed.
+
+Key Takeaways for Interviews:
+
+Thread safety is essential when multiple threads share a resource.
+Common issues include race conditions, deadlocks, and data inconsistency.
+Solutions include synchronization, locks, atomic variables, thread-safe collections, and immutable objects.
+Real-world applications include banking, ticket booking, cloud file editing, and e-commerce.