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

This might actually be a thing in machines exposed to radiation. Not sure where else it would be needed.

@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.

@tosensei gamma rays can easily flip bits in memory. From what I understand there are strategies employed in the software as well as hardware. Space is less protected than earth and cannot always have thick concrete or lead to stop the radiation.

@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.

@Fast-Nop The code I saw, which I cannot find, used a lottery. It was code supposedly to be used with satellite systems.

There are several tiers:

https://adass.org/adass/...

It sucks, but the links on Ada Fruit to the NASA docs are broken now.

The radiation hardened processors for space cost upwards of 200K. They are trying to use reduced cost hardware to lower that cost. One way to do this is algorithmic.

You cannot keep adding hardware in a space environment. It generates heat. You have to get rid of that heat. Black body radiation is your only way to cool. It is weird, but in space where it is very cold, heat is an issue in electronics.

Ada Fruit talked about the problem as well:

https://blog.adafruit.com/2019/08/...

@Fast-Nop I have heard of early on in hardware interfaces, before we got better signal debouncing, of software devs doing this to try and debounce the signal in code.

@Fast-Nop Voting system, not lottery, doh.

Anyway, here is someones take on the idea:

https://github.com/cwesson/rhs

@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.

@Fast-Nop Explain technically how verifying a bit is sufficiently or on/off is different in an input/output vs a boolean in memory in a radiation susceptible system? I don't see how the approaches would be that different.

@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.

@Fast-Nop I know these things. I came from a hardware background. But my original post was that I was suggesting a redundant check to determine a state. I have seen code both in hardware (microcontrollers) and from satellites that uses redundant checks to determine confidence in a state. How is using redundant checks sufficiently different in the 2 types of systems?

We also went from: they don't do that in software, to: well they do it in software but not exactly how you said.

@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.