🦥What Is a Race Condition?

Sponsored by

Hello humans.

Welcome to this week’s Sloth Bytes. I hope you had a nice week.

Learn AI in 5 minutes a day

This is the easiest way for a busy person wanting to learn AI in as little time as possible:

1. Sign up for The Rundown AI newsletter

2. They send you 5-minute email updates on the latest AI news and how to use it

3. You learn how to become 2x more productive by leveraging AI

Sign up to start learning.

What the Heck Is a Race Condition?

Let me be honest with you all.

I know absolutely NOTHING about parallelism and concurrency….

Hey don’t laugh. I use JavaScript, so it’s not surprising.

Anyways, I decided to study these concepts. (One of the reasons why I love this newsletter is I can share what I learn with you all 😁)

Alright buddy. I don’t care. Give me the info.

Alright fine.

There’s one specific concept I wanted to understand because I always hear about it, but never fully understood it.

It was one of those concepts where someone says it and I just nod.

Race conditions.

What is a Race Condition?

Let me paint a picture for you.

You’re building a multi-threaded app.

Two functions are running at the same time. Both trying to update the same value.

One increments, the other resets. You hit run.

And the result?

Sometimes it works. Sometimes it break. Sometimes it just… acts weird.

Welcome to the painful world of multithreading!

Race conditions are a common problem that doesn’t always crash your code but makes it dangerously unpredictable.

Technical Explanation: A race condition happens when a program's behavior depends on the timing of events. For example, if two threads try to use the same data at the same time, and one of them is changing it, this can cause problems.

Analogy:
Imagine two people trying to write on the same whiteboard at the same time. One’s trying to write “Hello,” the other “Goodbye.”

Depending on who starts or finishes first, you could end up with “Hellobye,” “Goodlo,” or complete gibberish.

Where Do Race Conditions Happen?

• Multithreaded applications (classic culprit)

• Asynchronous code (timing is unpredictable)

• Shared memory or variables (no locks = chaos)

Common real-world examples:

• Updating user data at the same time from two different threads

• Two bank transfers being processed simultaneously

• Async form submissions that overwrite each other

Why Are Race Conditions Dangerous?

Because they’re sneaky.

• They don’t always cause an error.

• They’re hard to reproduce.

• They make your software behave inconsistently.

Which means they can silently corrupt data or crash your program randomly after it's in production.

How Do You Prevent Them?

1. Locks / Mutexes: Ensure that only one thread can access a shared resource at a time (I’ll make a separate newsletter for these fun things later.)

Here’s a quick example:

import threading
# Lock our thread to prevent other threads from accessing it
# This prevents race conditions
lock = threading.Lock()
shared_value = 0

# Do whatever we need to do inside this block
with lock:
    # Everything inside this block is "acquired"
    # Basically our thread has exclusive access to this.
    # change our value
    shared_value += 1
# We finished what we needed to do.
# The lock is released outside the with block

2. Atomic operations: Operations that run completely or not at all—no in-between state.

3. Immutability: In some contexts, avoiding shared mutable state altogether is the easiest solution.

4. Thread-safe data structures: Some languages/libraries provide built-in structures that handle locking for you.

Race conditions don’t care how good your code looks or how many tests you wrote

They happen when you assume code will run in a specific order… but it doesn’t.

So anytime you’re working with threads, async logic, or shared state: slow down. Ask yourself if two things might step on each other’s toes.

If the answer is “maybe”

Then be safe and give your code some protection 😉 

To have a chance of being here, make sure to rate today’s newsletter!

Thanks to everyone who submitted!

bakzkndd, Apoll011, GabrielDornelas, triva03, AlePlaysDev, ShadowDara, JamesHarryT, pixelated-sys, porrrq, RelyingEarth87, ariatheroyal, E-Sieben, FredericoSRamos, SauravChandra10, jmadden21, and ElGonan.

Next Happy Year

Sloth needs your help to find out the next happy year.

A Happy Year is the year with only distinct digits (no duplicates).

Create a function that takes an integer year and returns the next happy year.

Examples

happyYear(2017)
output = 2018
# 2018 is the next happy year with all numbers being different.

happyYear(1990)
output = 2013
# 2013 is the next happy year with all numbers being different.

happyYear(2021)
output = 2031
# 2031 is the next happy year with all numbers being different.

How To Submit Answers

Reply with

• A link to your solution (github, twitter, personal blog, portfolio, replit, etc)

• or if you’re on the web version leave a comment!

• If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!

New video should come out this week!

It’ll be about how to use AI for programming where I cover how I like to use AI, useful strategies to feel more productive, and how to use it without sacrificing too much programming skills.

That’s all from me!

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake or you have any questions, feel free to comment below or reply to the email!

See you all next week.

Want to advertise in Sloth Bytes?

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.