5 ms·
Doing any modification to the source code to prevent this is not a good design. C/C++ is not designed for this use case, so it's going to create a mess if one w
by jacobsladder 10y ago
Doing any modification to the source code to prevent this is not a good design. C/C++ is not designed for this use case, so it's going to create a mess if one will try to work around this. This might lead to similar problems that premature optimization does to the code. Instead the solution should be on hardware level, like in airplanes. Put three computers in radiation environment. Then put a forth computer that'd analyze the computing results from the three computers and do action only when there 3 out of 3 or 2 out of 3 computers agree on the result. Or average / median can be applied, depending on the task. Ideally the fourth computer needs to be put in non-radioactive environment. If not possible, that still simplifies the problem somewhat. Because only the final forth computer who collects the data and selects the trustworthiness can contain bugs, not the rest of the code.
- jacobsladder 10y agoTo clarify, each piece of the puzzle must do what it is expected to do, otherwise it will be hacky. It's not expected for C++ program to detect its underlying hardware problems, there are no tools, nothing for that. So any solution would then look like and feel like a hack, temporary workaround. It's however expected for the computer as a whole to produce buggy results, it's normal and there are many existing design solutions that can take that into account and work around that. So that's why you take three computers and judge their output. Then each piece of the puzzle does it what it is intended to do, it does what it is expected to do and it doesn't do stuff outside of its responsibility.
- jacobsladder 10y agoSorry it looks like a flooding, but to add to that, having program self-check itself is also unnecessarily ties the program to its usecase in the radiation environment, it creates unnecessary strong dependency to its execution environment, and that just goes against all the good principles of design. It's like having a software for clock in the microwave machine be aware that it is placed in the microwave machine.
- nitrogen 10y agoGood principles of software design are simply different in different environments. The microwave clock knows it's a microwave because it controls the microwave. It would be wasteful to put extra layers of abstraction in such a small system. Likewise, a system designed for radiation tolerance will expect a close coupling between software and hardware; the whole point of the software in that case is the hardware.
- joelthelion 10y agoIf you want to address the problem at the software level, you could probably write a compiler for this. But that would be a massive undertaking...
- zzzcpan 10y agoMaybe not as massive as it seems. You could compile your code into llvm IR, work on that and compile to native code with llvm.
- mturmon 10y agoNot so fast: it's possible to have library-level fault tolerance, or OS-level fault tolerance, that is implemented in software, without having to change the source code much or at all. My perspective on this is informed by work on ABFT (for more on that, see https://www.computer.org/csdl/trans/tc/1984/06/01676475.pdf https://www.computer.org/csdl/trans/tc/1984/06/01676475.pdf, and the literally 1000 later papers citing it) -- you can design a version of the basic linear algebra subroutines that have fault-tolerance built in, and use them without changing program source code. For codes that spend a lot of time doing numerical computations (e.g., preliminary data reduction in a spacecraft on-board computer), ABFT is an interesting option.