Half Bug

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