4 ms·

Meta-stability [0] is a hardware issue, surely? Race conditions can create some crazy effects (BTDT) but at least they are fixable in software. [0] https://en.

by hazeii 7y ago

Meta-stability [0] is a hardware issue, surely? Race conditions can create some crazy effects (BTDT) but at least they are fixable in software. [0] https://en.wikipedia.org/wiki/Metastability_%28electronics%29 https://en.wikipedia.org/wiki/Metastability_%28electronics%2...

cornstalks 7y ago
I think the parent meant (emphasis on the scare quotes) “cosmic ray” type bugs as the kind of bugs we programmers sometimes attribute to cosmic rays, despite actually being a complex race condition.
- hazeii 7y ago
  Good point, happened I had one today that appeared impossible, yet (of course) it was easily understandable once the root cause was found. The Zebra test is a good friend. [0] https://en.wikipedia.org/wiki/Zebra_%28medicine%29 https://en.wikipedia.org/wiki/Zebra_%28medicine%29
ChuckMcM 7y ago
With all due respect to Wikipedia, the term meta-stability is applicable to any system issue where the behavior of the system is undefined when one or more of its inputs can be undefined. The inputs to "software" finite state machines are typically inputs in the form of variables. Those inputs define which branches within the routine will be taken during processing. You can model a subroutine as an FSM for which its "outputs" are its state, the FSM takes inputs, processes them, and sets new outputs or a new state. We use fuzzing to expose the state machine to all possible combinations of inputs and this identifies all possible exit states from all possible input states, but assumes the input states are stable. Multi-processing introduces the possibility of race conditions. In a race condition, one input state is present when the state machine is entered, but during execution the race completes which changes the input value. We use 'stable' to define an input that has the same value across the entire duration of the state machine's state execution. During a race condition, an input may change value one or more times across the time interval of the state machine's state execution. Thus at any instant in time the input has a singular value, during an interval in time that value may have many different values. These inputs are meta-stable. And yes, you can fix meta-stability in software with things like mutexes and execution exclusion. Just like you can fix meta-stability bugs in hardware signals by add a clock synchronization domain that spans the widest period of meta-stability possible for a signal. One of the things that makes race condition bugs so hard to debug is that your typical tracing facility assumes that the inputs passed to a function are stable and don't change. Thus you'll see a trace record of a function call, with its parameters, and walk through the code and say "Wait, with those parameters this code could never do what it just did." Or conversely, that variables that have shared write status across execution domains will be the same throughout a function. Does that make is clearer what I was talking about? Race conditions suck :-)
- eyko 7y ago
  I think Wikipedia would benefit from your contribution!

by hazeii 7y ago

cornstalks 7y ago

I think the parent meant (emphasis on the scare quotes) “cosmic ray” type bugs as the kind of bugs we programmers sometimes attribute to cosmic rays, despite actually being a complex race condition.

hazeii 7y ago
Good point, happened I had one today that appeared impossible, yet (of course) it was easily understandable once the root cause was found. The Zebra test is a good friend. [0] https://en.wikipedia.org/wiki/Zebra_%28medicine%29 https://en.wikipedia.org/wiki/Zebra_%28medicine%29

ChuckMcM 7y ago

With all due respect to Wikipedia, the term meta-stability is applicable to any system issue where the behavior of the system is undefined when one or more of its inputs can be undefined. The inputs to "software" finite state machines are typically inputs in the form of variables. Those inputs define which branches within the routine will be taken during processing. You can model a subroutine as an FSM for which its "outputs" are its state, the FSM takes inputs, processes them, and sets new outputs or a new state. We use fuzzing to expose the state machine to all possible combinations of inputs and this identifies all possible exit states from all possible input states, but assumes the input states are stable. Multi-processing introduces the possibility of race conditions. In a race condition, one input state is present when the state machine is entered, but during execution the race completes which changes the input value. We use 'stable' to define an input that has the same value across the entire duration of the state machine's state execution. During a race condition, an input may change value one or more times across the time interval of the state machine's state execution. Thus at any instant in time the input has a singular value, during an interval in time that value may have many different values. These inputs are meta-stable. And yes, you can fix meta-stability in software with things like mutexes and execution exclusion. Just like you can fix meta-stability bugs in hardware signals by add a clock synchronization domain that spans the widest period of meta-stability possible for a signal. One of the things that makes race condition bugs so hard to debug is that your typical tracing facility assumes that the inputs passed to a function are stable and don't change. Thus you'll see a trace record of a function call, with its parameters, and walk through the code and say "Wait, with those parameters this code could never do what it just did." Or conversely, that variables that have shared write status across execution domains will be the same throughout a function. Does that make is clearer what I was talking about? Race conditions suck :-)

eyko 7y ago
I think Wikipedia would benefit from your contribution!