Dev: Why do you have an identical if statement right below this one?

Manager: Because I want the code to double check, obviously.

Dev: …

What's the problem? He had just shown you how to get the same salary for doing half the work by repeating every statement. :D

@Demolishun but that's a problem that shouldn't be solved on code-level, but on hardware-level

@Demolishun @tosensei two CPUs on ship and both check each other. If they are inconsistent with their results they run the calculation again.

Makes sense to me.

@iSwimInTheC or three, and the result is two out of three vote.

I don't know if I'd feel comfortable if my programs had to take freak cosmic events into consideration as part of normal operation.

Then again, I'd probably be paid a lot more.

@Demolishun If you have that issue, which in this case certainly doesn't apply to begin with, you don't just repeat the statement, you duplicate the whole machine. Actually, you triple it. And you let the software be implemented and verified by three different teams. Then you do a voting on the results.

@Demolishun Debouncing is embedded standard practice, either in HW or in SW, and has nothing to do with SEU (single event upset) due to bit flipping.

Voting logic with redundant systems is what you do when you have critical systems. Critical as in, people may die if the shit hits the fan.

It's not even just the processors that will be redundant, that extends also to the sensors because they might fuck up as well.

See the 737-Max what happens when a system that became critical after design changes only evaluates one single sensor, and that sensor suffers from malfunction.

@Demolishun Debouncing: any mechanical input such as a microswitch will not change cleanly, but kick back and forth for around 10-20ms before settling on the new state. That's completely normal and has nothing to do with cosmic rays. You use either a HW Schmitt trigger or debounce the mess in SW.

The problem with bit flipping is much more difficult. You can't assume that only some bit in memory may flip because any bit may flip. Crucially, that includes bits in the program counter register so that under such conditions, you can't even rely on the program flow. It might continue at any place, not just where you'd expect.

That's the problem with digital technology: up until the fault threshold, faults don't manifest at all, but beyond that, there is no such thing as "mostly controlled". Either you are in control, then things are good, or you are not, and then all bets are off.

@Demolishun What's the point of a double check of a logical condition in software if that's meant to deal with circumstances where you can't even rely on your program counter?

That's like using a condom in a leprosy colony.

@Fast-Nop hell of an analogy 🤣

@TheCommoner282 not true. Bodies cool because they emit heat through heat radiation, without heat intake (like on the earth). Liquids cool down for the same reason, but at the same time the evaporation temperature is very low due to no pressure (vacuum), meaning water boils and freezes at the same time.

Net effects; things cool down, they don't keep their temperature due to "isolation"

@Demolishun problem is that if the bit got flipped it will likely be the same in both checks. Most alterations happen in transit to the CPU. It's not going to load the value twice. Chances are that the compiler even completely optimizes the duplicate away.