s constitute the fundamental problem with unsupported / inadequately supported concurrency programming.
produces a bug that may be expected to occur occasionally. Similar RaceCondition
bugs that may exist will be expected to occur with their own periodicity. The entire class of RaceCondition
bugs that may be expected to exist will exhibit an 80/20 rule / ParetoDistribution?
, or something like a half-life distribution -- ergo HalfBug
If one HalfBug
is found, the existence of additional HalfBug
s should be inferred. BlackBoxTesting
cannot be relied on to find (all) HalfBug
s. The user-base CAN be relied on to find all relevant HalfBug
Microsoft's approach to experimentally finding relevant HalfBug
s is perhaps the only relatively effective BlackBox
("Click yes to send bug-report") allows the full run-time of a significant portion of the installed user-base to act as a test-bed for finding low-probability HalfBug
Implication: If testing cannot be relied on to find HalfBug
s, and if one's development environment cannot be relied on to prevent one from writing HalfBug
s, concurrent code cannot be considered to be fully reliable. The reasonable expectation is that such code will fail regularly.
Assuming that all bugs encountered during testing were resolved (a grossly unreasonable assumption), then one might extrapolate a per-user BugFrequency?
of half the total CPU-time spent in BlackBox
testing. In fact, given the likelihood of substantially greater installed-base variability versus testing variability, one should expect a substantially higher bug frequency. -- HankHoek
Suggest merging with HeisenBug