Archive

Posts Tagged ‘deadlocks’

3 easy steps to improve quality of your concurrent programs

February 12th, 2014 No comments

Weinberg’s Second Law says that if builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy the civilization. In practice it means that any software has to be tested very carefully to fix bugs in it in the earliest stage of its lifecycle.

Rapid expansion of multicore and multiprocessor systems makes software developers write parallel programs to use system resources as efficiently as possible. And here another big hazard is hidden – errors, related to incorrect usage of multiple threads of execution. On big production servers it’s a much bigger threat than it seems, because the program code is physically executed on different cores or processors, and concurrent issues arise in their full capacity. Most well-known problems of such a kind are deadlocks and data races. All concurrent issues are hard to detect manually or by testing, because their nature is essentially nondeterministic. Data race detection is an especial issue, because the effect of their occurrence may become apparent much later. When a data race occurs, global data are corrupted, but the application itself doesn’t halt, it continues to work with incorrect data, and who knows when one would notice it. Data races may be really dangerous – e.g. data race was the cause of accidents with Therac-25, the radiation therapy machine, that gave massive overdoses of radiation to six patients. Also data race was one of the causes that led to the Northeast blackout of 2003 that affected more than 50 million people in the US and Canada.

Good news Read more…