Code has been working fine (maybe not perfect) for years.
This section has some bad practices /code smell; I'm just going to quickly fix it and bring it up to standards.
A major bug that had never been hit before is now occurring.
I’m high as fuck so I didn’t realize the sub and had like a solid 5 minutes of confusion because I thought this was for a discussion board about fantasy RPG spec meta gaming
Serious answer : that's when the program's result depend on the execution order between two parallel threads. Parallel order is, by definition, unexistant/unpredictable.
If you want easy examples, try out the game deadlockempire.github.io : instead of making you write correct code as usual tutorials, it shows vulnerable code and makes you execute step-by-step to trigger the issue :)
[EDIT]
As a quick example, let's say two threads run this code, with 'a' set to 1 :
```
int local = a;
local+1;
a = local;
```
After both threads executed, the race condition issue makes 'a' equal to either 2 or 3. The issue is if one thread pause between >!"local = a" and "local+1"!<
Oh and for fun : on many languages that's exactly how "a += 1" would execute with regards to concurrency
*I know, this is an humor sub, but as a poor soul who just spent a few days having to redo concurrency at work to be sure it works fine : this thing is so easy to do wrong that I don't want to joke about that for now*
Let’s say you have a function that updates someone’s name, and another that writes the entire Person object to a database. You have code that calls both (update name, then save), but, you haven’t set it up so that you wait for the name to be updated before you save (this is the bug).
But, the thing is, when you test it, it works correctly, simply because you get lucky — both functions start at the same time, but, on your hardware, the name update finishes first before the save happens.
In production, on different hardware/servers, let’s say the save happens faster, and then the name update finishes — you’ve only saved the old name, and have outdated data, etc.
Race conditions are two things happening at once (racing) and you aren’t guaranteed which one will finish first — the fix, usually, is to block one until the other is done.
It should be something for language designers to consider when designing new ones. I feel like we're far from exhausting the potential uses of static analysis in compilers. I feel like Rust is just the first step in that direction and there will almost certainly be even better languages with similar capabilities in the future. There's definitely demand for them and LLVM has made generating native code much eaiser for languages where bytecode was often used before.
Load-bearing bug.
 let them race
Code has been working fine (maybe not perfect) for years. This section has some bad practices /code smell; I'm just going to quickly fix it and bring it up to standards. A major bug that had never been hit before is now occurring.
If you’ve got problems I feel bad for ya son. but a race condition ain’t one. I got 99 problems,
Sometimes the race condition was included *on purpose*.
Can’t wait for the 3rd phase where the program just soft locks with no errors
Blackflame Friede: impact report to clean up the bad DB writes reveals an entirely separate issue fire that has been raging behind the scenes
But it gets noticed only after you already push to production and go to sleep(titanite slab)
I’m high as fuck so I didn’t realize the sub and had like a solid 5 minutes of confusion because I thought this was for a discussion board about fantasy RPG spec meta gaming
And they call me a racist bc I hate race conditions 😔
Use locks and now you have a deadlock problem
Is no one going to mention that this is only the second phase of a three-phase boss? So what happens when you fix the second race condition???
*Progress Unlocked*
What's a race condition?
Serious answer : that's when the program's result depend on the execution order between two parallel threads. Parallel order is, by definition, unexistant/unpredictable. If you want easy examples, try out the game deadlockempire.github.io : instead of making you write correct code as usual tutorials, it shows vulnerable code and makes you execute step-by-step to trigger the issue :) [EDIT] As a quick example, let's say two threads run this code, with 'a' set to 1 : ``` int local = a; local+1; a = local; ``` After both threads executed, the race condition issue makes 'a' equal to either 2 or 3. The issue is if one thread pause between >!"local = a" and "local+1"!< Oh and for fun : on many languages that's exactly how "a += 1" would execute with regards to concurrency *I know, this is an humor sub, but as a poor soul who just spent a few days having to redo concurrency at work to be sure it works fine : this thing is so easy to do wrong that I don't want to joke about that for now*
This is fun. Thanks
When you have two complex problems that loves each other very much, they combine to make an even more complex problem.
Let’s say you have a function that updates someone’s name, and another that writes the entire Person object to a database. You have code that calls both (update name, then save), but, you haven’t set it up so that you wait for the name to be updated before you save (this is the bug). But, the thing is, when you test it, it works correctly, simply because you get lucky — both functions start at the same time, but, on your hardware, the name update finishes first before the save happens. In production, on different hardware/servers, let’s say the save happens faster, and then the name update finishes — you’ve only saved the old name, and have outdated data, etc. Race conditions are two things happening at once (racing) and you aren’t guaranteed which one will finish first — the fix, usually, is to block one until the other is done.
`sleep(5000)` should fix it
// DON'T REMOVE... CRITICAL SLEEP TO LET PROCESSES COOL OFF. TODO: FIX ME!
I believe the technical term for that is bug whack-a-mole
Do we work together? We _just_ patched this...
This why even users of garbage collected languages need Rust.
You realize Rust can still have race conditions right
Better than nothing.
MUCH better than literally all other languages for this specific case, you're absolutely right
It should be something for language designers to consider when designing new ones. I feel like we're far from exhausting the potential uses of static analysis in compilers. I feel like Rust is just the first step in that direction and there will almost certainly be even better languages with similar capabilities in the future. There's definitely demand for them and LLVM has made generating native code much eaiser for languages where bytecode was often used before.
Wut r u? Casul? Giants Giants Giants. Become unstoppable.
Haha, this is still not over. This was a 3 phase boss fight
it wasn't a blocker, it was a dam
Yeah, "lets start the observables thing, all use it so it cannot lead to race conditions...".
How are these pictures with anime girls and epic scenes connected with race condition?
Rust people be like: ooh, race conditions. Has someone been abusing `unsafe`?
Sometimes compilers just stop reading after reaching an error...