3 ms·
> Then we need a term for when code race conditions are possible but rare enough that nobody using the software notices. thread-timebomb? There's already a ter
by nuerow 5y ago
> Then we need a term for when code race conditions are possible but rare enough that nobody using the software notices. thread-timebomb?
There's already a term for that: not thread-safe.
The definition of thread safety does not include theoretical or practical assessments regarding how frequent a problem can occurr. It only assesses whether a specific class of problems is eliminated or not.
- jldugger 5y ago>The definition of thread safety does not include theoretical or practical assessments regarding how frequent a problem can occur. Well, obviously. The challenge I am putting forth on HN is to meaningfully describe _usable_ thread-unsafe software. If you've spent enough time outside university, you'll be aware that there are all kinds of theoretical race conditions that are not triggered in practical use.
- klyrs 5y agoIf you've worked at industrial scale, you'll be aware that even the most theoretical-seeming race condition will be triggered frequently.
- jldugger 5y ago> If you've worked at industrial scale, Fun fact, I actually do! It's from that perspective I wrote that: every time you perturb the software environment, a new set of bugs that didn't happen in the old env before arises.
- The_Colonel 5y agoThat reminds me how I was called to fix some Java service, which was successfully in production for 10 years with hardly any incident, but it suddenly started crashing hard, all the time. It was of course a thread safety issue (concurrent non-synchronized access to hashmap) which laid dormant for 10 years only to wreak havoc later. Nothing obvious changed (it was still running a decade old JRE), perhaps it was a kernel security patch, perhaps a RAM was replaced or even just the runtime data increased/changed in some way which woke up this monster.