Search Wiki:
Resource Page Description
It is the dawning of the age of many-core. While machines from desktops to netbooks sport no less than dual core processors under the hood, throngs of hungry transistors sit idle—crying for multithreaded applications to devour. To address the oncoming wave of concurrent applications, companies like Intel and Microsoft race to market with profilers, frameworks, debuggers and libraries. As multithreaded applications proliferate, so too will discussions of deadlocks, live locks and data races become increasingly common across the software industry. Traditional testing metrics such as statement, block, and branch code coverage fail to address test adequacy concerns introduced by concurrency. While full statement coverage can often be achieved with only single threaded tests, it provides no visibility into the concurrency behavior of the software under test. We need something better. Synchronization coverage aspires to fill this gap by measuring the amount of contention that occurs within a test. In this article, we illustrate the concept of synchronization coverage; discuss the types of problems that can be addressed by this metric; and provide a sample tool that measures synchronization coverage for managed code.

This article is available at:
Last edited Aug 5 2009 at 2:22 AM  by adargel, version 2
Page view tracker