# I think we’ve got a serious race condition **Brian:** I was checking the logs from last night, and I think we’ve got a serious `race condition`. Some of the payment statuses are being `overwritten`. **Ingrid:** Overwritten? As in, two processes updating the same row at the same time? **Brian:** Exactly. The jobs `run in parallel`, and the updates aren’t `atomic`. One thread marks the payment as *completed*, and almost immediately another marks it as *failed*. **Ingrid:** Classic `data race`. So we’re basically losing consistency because the order of execution isn’t guaranteed. **Brian:** Yep. It’s completely `non-deterministic`. Sometimes it passes, sometimes it breaks, depending on how the scheduler `interleaves the operations`. **Ingrid:** `That’s messy`. Are we using any synchronization at all? `Mutex`, `semaphore`, even a simple database-level lock? **Brian:** Nope. Right now it’s just `raw updates` against the shared state. No lock, no transaction, nothing. **Ingrid:** Okay, then it’s not `thread-safe` at all. We should at least `wrap that code` in a critical section. **Brian:** My only concern is performance. If we put a lock around the whole thing, we might create `contention` or even `deadlocks`. **Ingrid:** True. But we don’t need to lock the whole workflow, just the part where the shared record gets updated. Keep the critical section as small as possible. --- ### Vocabulary | `atomic` | `deadlocks` | `contention` | | --- | --- | --- | | `raw updates` | `wrap that code` | `thread-safe` | | `That’s messy` | `non-deterministic` | `interleaves the operations` | | `race condition` | `overwritten` | `run in parallel` | ### Vocabulary **Atomic** * *Meaning:* An operation that happens completely or not at all. Nothing can interrupt it midway. * *Example:* “The update must be atomic so that no other thread can mess with it while it’s running.” **Deadlocks** * *Meaning:* A situation where two or more processes are waiting for each other forever, and nothing moves forward. * *Example:* “If thread A holds Lock 1 and waits for Lock 2 while thread B holds Lock 2 and waits for Lock 1, you’ve got a deadlock.” **Contention** * *Meaning:* When multiple processes or threads are trying to use the same resource at the same time, causing slowdowns. * *Example:* “Too many threads writing to the database creates contention.” **Raw updates** * *Meaning:* Direct changes to the data without any safeguards like transactions or locks. * *Example:* “We’re doing raw updates on the table, so nothing is protecting us from conflicts.” **Wrap that code** * *Meaning:* Put the code inside a structure (like a lock or transaction) to make it safe. * *Example:* “We should wrap that code in a mutex to avoid race conditions.” **Thread-safe** * *Meaning:* Code that works correctly even when multiple threads run it at the same time. * *Example:* “This function isn’t thread-safe—it fails when two users hit it simultaneously.” **That’s messy** * *Meaning:* Informal way of saying something is confusing, hard to manage, or poorly controlled. * *Example:* “Two different states being written at the same time? That’s messy.” **Non-deterministic** * *Meaning:* The result is unpredictable and can change depending on timing or execution order. * *Example:* “The test is non-deterministic—it passes sometimes and fails other times.” **Interleaves the operations** * *Meaning:* When the system mixes pieces of different processes or threads together during execution. * *Example:* “The scheduler interleaves the operations, so thread A and thread B take turns running.” **Race condition** * *Meaning:* A bug that happens when two processes or threads try to use the same resource at the same time, and the result depends on who “wins the race.” * *Example:* “Updating the counter without a lock caused a race condition.” **Overwritten** * *Meaning:* When new data replaces old data, sometimes unintentionally. * *Example:* “The first update marked the payment as complete, but it got overwritten by the second update.” --- ## Exercises ### Fill in the blank 1. An \_\_\_\_\_\_\_\_\_\_\_\_ operation cannot be interrupted; it either completes fully or not at all. 2. When two threads wait for each other forever, it causes a \_\_\_\_\_\_\_\_\_\_\_\_. 3. Multiple processes trying to access the same resource at the same time creates \_\_\_\_\_\_\_\_\_\_\_\_. 4. Directly updating data without using locks or transactions is known as \_\_\_\_\_\_\_\_\_\_\_\_. 5. Developers often say “\_\_\_\_\_\_\_\_\_\_” when they want to put risky code inside a safe structure like a lock. 6. If a method works reliably even when multiple threads call it, we say it is \_\_\_\_\_\_\_\_\_\_\_\_. 7. “\_\_\_\_\_\_\_\_\_\_” is an informal way to describe code that produces confusing or inconsistent results. 8. A process is \_\_\_\_\_\_\_\_\_\_\_\_ when its result is unpredictable and changes depending on timing. 9. The scheduler sometimes \_\_\_\_\_\_\_\_\_\_\_\_ the operations, letting pieces of different threads run in sequence. 10. A \_\_\_\_\_\_\_\_\_\_\_\_ happens when the outcome depends on who “wins” access to a shared resource first. 11. When one update accidentally replaces another, the data is said to be \_\_\_\_\_\_\_\_\_\_\_\_. 12. To avoid a \_\_\_\_\_\_\_\_\_\_\_\_, it’s best to acquire locks in a consistent order across all threads. 13. Using a database transaction can make an update behave like an \_\_\_\_\_\_\_\_\_\_\_\_ operation. 14. The performance issue that occurs when too many threads wait for the same lock is called \_\_\_\_\_\_\_\_\_\_\_\_. 15. Writing to shared state without synchronization often leads to a \_\_\_\_\_\_\_\_\_\_\_\_ condition. 16. A result that is not consistent between runs, even with the same inputs, is \_\_\_\_\_\_\_\_\_\_\_\_. 17. To protect shared variables, engineers often \_\_\_\_\_\_\_\_\_\_\_\_ the code that modifies them. 18. If a system is not \_\_\_\_\_\_\_\_\_\_\_\_, it may crash or corrupt data under concurrent access. 19. When log entries show two different values being written at the same time, it’s a sign of being \_\_\_\_\_\_\_\_\_\_\_\_. 20. Debugging is harder when execution is \_\_\_\_\_\_\_\_\_\_\_\_, because you can’t predict the exact order of steps. --- ### Reading comprehension **1\. What problem did Brian find in the logs?** a) The system was too slow b) Payment statuses were being overwritten c) Users couldn’t log in d) The database was offline **2\. How does Ingrid describe the situation where two processes update the same row at the same time?** a) A deadlock b) A race condition c) Contention d) Non-determinism **3\. Why does Brian call the results “non-deterministic”?** a) Because they depend on who logs in first b) Because they are predictable c) Because the outcome changes depending on execution order d) Because the database is corrupted **4\. What does Ingrid ask about synchronization?** a) If they are using caching b) If they are using locks or other synchronization tools c) If they are using AI to optimize scheduling d) If they are using a new payment API **5\. What is Brian’s reply about synchronization?** a) They are using transactions for every update b) They only use semaphores c) They are doing raw updates with no protection d) They disabled synchronization for performance **6\. What does Ingrid suggest to make the code safer?** a) Rewrite the system from scratch b) Wrap the update in a critical section c) Add more servers d) Disable parallel processing **7\. What concern does Brian raise about using locks?** a) It might cause data loss b) It might create deadlocks or slowdowns c) It might make the UI ugly d) It might reduce test coverage **8\. How does Ingrid respond to Brian’s concern?** a) She says to avoid locks completely b) She suggests locking only the critical section c) She suggests running the code without synchronization d) She suggests adding more threads **9\. What alternative solution does Brian propose?** a) Making the operation idempotent b) Restarting the system every night c) Removing database indexes d) Using only one thread for all jobs **10\. What final step does Brian decide to take?** a) Test it with a lock around the update first b) Do nothing and ignore the issue c) Rewrite the database schema d) Remove the payment feature --- ## Homework ### Produce Write a short dialogue between **two developers** who discover a bug caused by a race condition. * Use **at least 5 of these words/phrases**: \[*atomic, deadlock, contention, raw updates, thread-safe, non-deterministic, overwritten, race condition,* interleaves the operations, That’s messy, *wrap that code \]* atomic --- ### Personal connection Think about any real project or exercise (class project, homework, internship, or job). Describe your personal experience in the topic. --- ## Done ---