CHESS release v0.1.30610.2: Data Race Detection, ChessBoard, Refinement Checking

  • Article

The CHESS team is happy to announce a new release of CHESS, which includes a whole bunch of new features for concurrency testing of managed code and fixes for bugs reported on the CHESS MSDN forum (see the Channel 9 movie). Major features in this release include:

1. Data race detection for managed code;

2. ChessBoard, an interactive shell for CHESS that simplifies the typical user interactions with CHESS, such as launching CHESS runs and managing test results (it is especially useful for finding and reproducing data races);

3. Refinement checking for comparing the observed concurrent behaviors of a concurrent data type with its observable serial behaviors. 

Data Race Detection

By default, CHESS places preemptions in your code at before every synchronization call (like Monitor.Enter), before every volatile access (read or write), and before every interlocked operation. If you have two threads accessing the same (non-volatile) memory location without synchronization or an interlocked operation, your program probably has data races, which can lead to unpredictable behavior. With data race detection (/detectraces), you now can find this important class of errors with CHESS. The screen snapshot below shows a data race found with CHESS in Stephen Toub’s ThreadPoolWait example from MSDN.

Data Race

ChessBoard

The main goals of ChessBoard are to simplify simultaneous running of multiple tests and viewing of multiple results, quick repro & display of failing testcases and races, simplify experimentation with various CHESS parameters. The screen snapshot below shows the organization of ChessBoard into four panes: Test View, Task View, Result View, and Detail View.

ChessBoard

Refinement Checking

When creating large suites of small concurrent tests, it can be cumbersome to write tight assertions that validate the behavior of the tested code. A new CHESS feature, refinement checking, simplifies this task for the case of concurrent data types, by comparing the observed concurrent behaviors with the observable serial behaviors.

Controlling Execution Time of CHESS

- /maxexecs:N, the maximum number of thread schedules CHESS should explore (default: unlimited)

- /maxexectime:N, the maximum number of seconds an execution of ChessTest.Run is allowed to take (default: 10 seconds)

- /maxchesstime:N, the maximum number of seconds the entire CHESS explorartion is allowed to take (default: unlimited)

Other New Options

- /diagnose, prints (at the end of the CHESS run) which types were instrumented and which were not.

- /showprogress, to make CHESS periodically print an estimate of how many schedules remain to be explored

- /processorcount:N, makes Environment.ProcessorCount return the value N (N>=1). By default, mchess returns 1 whenever Environment.ProcessorCount is called. Very useful for testing code that spins based on processor count.

- /outputprefix, prefix to prepend before each file CHESS reads/writes (sched, results.xml, etc). Very useful if you are doing multiple CHESS runs in the same directory.

Other Features and Fixes:

- New samples:

    • ThreadPoolWait Sample (data race)
    • SimpleBank Sample (data race)

- /volatile is on by default (use /volatile- to turn off)

- mchess now handles

    • BeginInvoke/EndInvoke
    • Join with timeout
    • WaitOne with timeout