HalfBugs constitute the fundamental problem with unsupported / inadequately supported concurrency programming.
Deriving
HalfBug from half-life:
A
RaceCondition 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 /
LogNormalDistribution, or something like a half-life distribution -- ergo
HalfBug.
If one
HalfBug is found, the existence of additional
HalfBugs should be inferred.
BlackBoxTesting cannot be relied on to find (all)
HalfBugs. The user-base CAN be relied on to find all relevant
HalfBugs.
Microsoft's approach to experimentally finding relevant
HalfBugs is perhaps the only relatively effective
BlackBox solution.
DrWatson ("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
HalfBugs.
Implication: If testing cannot be relied on to find
HalfBugs, and if one's development environment cannot be relied on to prevent one from writing
HalfBugs, 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
See
RaceCondition
Suggest merging with
HeisenBug.
CategoryBug