HalfBug''''''s 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 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''''''s.

Microsoft's approach to experimentally finding relevant HalfBug''''''s 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 HalfBug''''''s.

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
----
See RaceCondition
----
Suggest merging with HeisenBug.
----
CategoryBug