CHESS: Find and Reproduce Concurrency Heisenbugs

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

CHESS Tool — Fri, 12 Jun 2009 21:15:00 GMT

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.

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.

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

Getting the most out of CHESS

CHESS Tool — Tue, 17 Feb 2009 09:59:00 GMT

Hi, this is Shaz Qadeer from the CHESS team. If you have visited our blog before, you have probably read our articles about systematic concurrency testing using CHESS, design of the CHESS scheduler, and the advantages of CHESS testing over stress testing. Hopefully, these articles have convinced you that there is substantial value in using CHESS to test your concurrent programs. In this article, I will try to explain the best practices in using CHESS. In other words, I will attempt to answer the question: How do I get the most out of CHESS?

Before I answer that question, I would like to review the anatomy of a test suitable for being used with CHESS. A CHESS test comprises three functions: ChessTestStartup, ChessTestRun, and ChessTestShutdown. Given these functions, CHESS performs the following computation:

ChessTestStartup();

while (exists unexplored schedule) {

ChessTestRun();

}

ChessTestShutdown();

After executing ChessTestStartup once, ChessTestRun is executed repeatedly, each execution taking a different schedule of the multithreaded scenario in ChessTestRun. If an execution results in a crash, manifested either as an assertion failure or an uncaught exception, then CHESS terminates. At this point, CHESS provides you with the capability to execute ChessTestRun along the thread schedule that caused the crash. If no error is found, the test finishes after executing ChessTestShutdown.

The most important aspect of using CHESS is to identify the concurrency scenario to be tested. For example, suppose we want to test a concurrent non-blocking queue data structure that supports two operations Enqueue and Dequeue. There are several interesting concurrency scenarios for this data structure, e.g., two Enqueue operations in parallel, two Dequeue operations in parallel, an Enqueue and a Dequeue in parallel, etc. Each of these scenarios should be given to CHESS as a separate test. Remember that CHESS is systematically searching the huge set of executions of a concurrent program and the number of executions increases exponentially with the size of the program. You can help CHESS by factoring out your large test into a collection of smaller scenario tests.

To test the first scenario of two parallel Enqueue operations, ChessTestStartup and ChessTestShutdown should be empty and ChessTestRun should perform the following sequence of operations:

1. Allocate and initialize the queue.

2. Create two threads each calling the Enqueue operation once, wait for the threads to finish, and reset the queue.

3. Free the queue.

Two aspects of step 2 in ChessTestRun are worth noting. First, it makes each thread perform an operation only once. This is in sharp contrast to the approach of stress testing, where each thread is usually made to repeat the same operation many times. Repetition is built into the CHESS framework (see the pseudo-code above), so your test does not have to do it. Second, ChessTestRun waits for all child threads to finish and resets the queue state. This is important because CHESS expects every execution of ChessTestRun to end in a state that is equivalent to the state at the beginning. You can do this by simply waiting for all threads, releasing all handles and resetting any global state used by the test. If ChessTestRun does not satisfy this property then CHESS might be unable to reproduce a bug discovered during its search. We have observed that most scenarios naturally satisfy this property. But sometimes global or static variables are initialized lazily during the first execution of ChessTestRun, thereby making the states at the beginning and end of the first execution of ChessTestRun different from each other. This problem is easily fixed though; just call ChessTestRun a couple of times at the end of ChessTestStartup. This is often sufficient to trigger all lazy initialization in the test. With this trick, subsequent calls to ChessTestRun have the same begin and end states.

For testing the non-blocking queue, we didn’t really use ChessTestStartup and ChessTestShutdown. These functions tend to be used relatively infrequently for the expensive part of test setup and teardown. For example, if the test connects to a database server, then the connection to the server could be established in TestStartup and torn down in TestShutdown.

Now, imagine that CHESS successfully generates all executions of the test with two threads each calling the Enqueue operation without finding an error. What does that say about the executions of a test with three such threads? Theoretically, the test with three threads may uncover a bug that does not occur with two threads. At the same time, the number of possible executions grows exponentially with the number of threads; consequently, testing with large number of threads will consume exponentially more testing resources. So what should our testing strategy be?

The systematic testing approach of CHESS is predicated upon the small-scope hypothesis: the likelihood of finding new errors in a parameterized system goes down as the parameter values are increased. In other words, systematic exploration of executions for small parameter values is highly effective in flushing out many bugs. A large amount of empirical evidence supporting this hypothesis has been obtained by us and by others working in the broad area of formal analysis of computer systems. An implication of the small-scope hypothesis is that an iterative strategy works best. Start with a small number of threads and increase the number gradually depending on your testing resources. This strategy also has the advantage that you get partial yet quantifiable coverage as exploration for a given number of threads is finished.

Another way to look at this testing strategy is as follows. If a bug requires a minimum of three threads, run CHESS with exactly three threads. Unlike stress, CHESS is guaranteed to find this bug. By iteratively increasing the number of threads, you are increasing the complexity of the bugs you find and the coverage achieved. Another advantage of this iterative strategy is that for every bug found, you find the simplest scenario that triggers the bug. This tremendously improves your debugging experience.

Finally, I would like to mention some common difficulties our users have encountered in creating a test suitable to be used with CHESS. For each issue, we also describe a possible workaround.

1. A background thread starts during ChessTestStartup and finishes during ChessTestShutdown. This thread executes outside the control of CHESS, since CHESS controls the scheduling of only the threads created during the execution of ChessTestRun. If this thread modifies the state of the test, then CHESS’ mechanism for reproducing executions may get confused. The simplest workaround is to make ChessTestStartup and ChessTestShutdown be a part of ChessTestRun, thereby bringing the background thread under the control of CHESS. Of course, you will now pay the performance penalty of having the startup and shutdown code exceuted during each iteration of ChessTestRun.

2. ChessTestRun uses a custom threadpool, perhaps implemented using System.Threading or WIN32 threads, to schedule tasks asynchronously. In such threadpool implementations, threads are often allocated dynamically and the number of threads may not be the same at the beginning and end of ChessTestRun. In this case, the fix is to implement a shutdown function that tears down all internal threads in the threadpool and ensure that this function is called at the end of ChessTestRun.

Well, that is all I have to say for now. There is a lot of information here on how to use CHESS effectively. I hope it helps all you CHESS enthusiasts out there. Please do let me know if you have any questions.

Best regards,

Shaz

Stress vs. CHESS

CHESS Tool — Tue, 03 Feb 2009 02:29:50 GMT

Hey there... it's time for another post. My name is Sebastian Burckhardt, I am a member of the CHESS team, and I want to tell you about some experiments I ran today. The question that interests me here is how does CHESS compare to stress testing ?

First, let me clarify the difference between the two. In general, the purpose of stress testing is to find all sorts of deficiencies under heavy load, including performance problems, excessive memory consumption, or insufficient reliability under failures. For example, we may create stress by using very large files or databases, or by processing a very large number of requests.

In contrast, CHESS specifically targets concurrency errors such as race conditions, synchronization errors or deadlocks. Even though such errors have nothing to do with stress per se, programmer often use stress testing to find them. Why is that so? I believe the answer is that stress can create unusual interleavings. When under heavy load, the relative speed of threads changes because some operations are slowed down while others are not. This helps to uncover synchronization errors. Thus, we can consider improved interleaving coverage a (secondary) effect of stress testing. Clearly, it's not the original purpose of stress. Nor is arbitrary creation of "stress" very efficient, as we will see later.

CHESS on the other hand is all about systematic coverage of interleavings. It's its primary purpose! So, while it will definitely not find problems related to files being too large, it does a terrific job at finding concurrency errors.

We're now going to try to find a bug with both stress testing and with CHESS (here is where the fun starts). First, go ahead and download & install CHESS (or just keep reading). Then, open the Account example (use VS to open Samples/Managed/BankAccount/Bank.sln). It contains the buggy "Account" class:

The bug is in the Withdraw() method: the Read() should happen inside the critical section. Here is the unit test that is designed to this bug:

    [TestClass]
    public class TestBank
    {
        [TestMethod]
        public void WithdrawAndDepositConcurrently()
        {
            var account = new Account(10);
            var child = new Thread(
               o => { (o as Account).Withdraw(2); }
               );
            child.Start(account);
            account.Deposit(1);
            child.Join();
            
            Assert.AreEqual<int>(9, account.Read());
        }

When running this test, a child thread is created. The original thread and the child thread then both make method calls to the same account object (calling Deposit(1) and Withdraw(2), respectively). As the starting balance was 10, the ending balance should be 9 if all goes well. However, because of the bug, there is a chance that we end up with a balance of 8 (because of the following scenario: the child thread calls Withdraw(2), reads a balance of 10, then gets preempted; the original thread now calls Deposit(1), updating the balance to 9. Finally, the child thread resumes, writing a balance of 8).

What are our chances of hitting the bug with this test?

As you may have guessed, they are not very good. You can try running this test a couple of times... it never failed for me. So, next step: stress. We'll start by simply repeating the test, first 1 thousand times, then 10 thousand times, then 100 thousand times. Note that we're using Release build type here (you may want to use smaller numbers for Debug build type).

[TestMethod]
public void Repeat1k()
{
    for (int i = 0; i < 1000; ++i)
        WithdrawAndDepositConcurrently();
}

[TestMethod]
public void Repeat10k()
{
    for (int i = 0; i < 10000; ++i)
        WithdrawAndDepositConcurrently();
}

[TestMethod]
public void Repeat100k()
{
    for (int i = 0; i < 100000; ++i)
        WithdrawAndDepositConcurrently();
}

We also add a CHESS test. Note that we need no loop here. CHESS has stress "built-in" because it already tries to systematically cover all interleavings, implicitly repeating the test many times. In fact, a loop would be a bad idea, since it would overwhelm CHESS.

[TestMethod]
[HostType("Chess")]
public void RunOnceWithChess()
{
    WithdrawAndDepositConcurrently();  // no need to write a loop
}

Now, let's run this (choose Tests->Run->All Tests in Solution from the menu) and look at the results, sorted by test duration.

As you can see, the original test (WithdrawAndDepositConcurrently) and the shortest stress test (Repeat1k) did not find the bug, but CHESS (RunOnceWithChess) and the two larger stress tests (Repeat10k, Repeat100k) both did.

Note that CHESS was a little faster than stress. Still, stress testing seems to work. So why do we need CHESS?

The answer is: because even under stress, the scheduler tends to heavily favor some interleavings over others. Specifically, there is some basic notion of fairness among threads, which makes it unlikely that a thread that is ready to execute is held back for a very, very long time.

We can demonstrate this by making a small change to the Account class, by adding a call to WasteTimeOnMeaninglessComputation() to the Deposit() method.

public void Deposit(int amount)
{
    WasteTimeOnMeaninglessComputation();
    lock (this)
    {
        balance = balance + amount;
    }
}

public void WasteTimeOnMeaninglessComputation()
{
    double dummy = 0;
    for (int i = 0; i < 50000; i++)
    {
        dummy += Math.Sin(i);
    }
    System.Console.WriteLine(dummy);
}

Of course, the Account class is just as broken as it ever was. We have just added some arbitrary delay to the thread calling the Deposit method. We can easily imagine how that may happen in a real program (for example, some heavy initialization may take place there, or the user may instrument the program to output lots of trace information to the console, maybe even in an attempt to debug a Heisenbug).

The interesting thing is that this little change throws off the stress testing:

Even with a 100k repetitions (which now take a lot longer), stress testing did not find the bug. Of course, CHESS is completely unimpressed by our change and finds the bug just as quickly as before.

So, what's the point? Is stress a bad thing? No. Clearly it does work, at least sometimes. Maybe if we try a couple more times, maybe if we run more tests, maybe if we change some numbers, maybe if we run on a different machine we'll find the bug (some teams run stress tests for days). Indeed, we tried the same tests and some small variations on a couple machines here and sometimes the bug was found. But then again, maybe we will never find it (there is no guarantee that running forever will eventually try all schedules, because the operating system scheduler is not a perfectly random thing). It's just not reliable, and definitely not quick. Also, it's not fun to reproduce and fix a bug that manifests only after days of running on some special machine.

I believe this simple experiment is making a strong case for using CHESS to find concurrency bugs in unit tests.

The CHESS scheduler – the key to finding concurrency bugs

CHESS Tool — Tue, 20 Jan 2009 12:34:10 GMT

Hey everyone, I am Madan Musuvathi, the architect of CHESS. In this blog, I will describe the CHESS scheduler, a key component of CHESS. Before I start, if you haven’t seen Tom’s previous post about the CHESS Devlabs release, you should. Download CHESS, play around, and let us know what you think.

When CHESS attaches to your program, it takes complete control over the scheduling of threads in your program. You are no longer at the mercy of the Windows scheduler, which can nondeterministically preempt your threads whenever it wants. Instead, CHESS, and indirectly you, the user, decide how the threads interleave during execution. This allows CHESS to systematically drive your program along possible interleavings, hunting for bugs. Also, once CHESS finds a bug, the repro is as easy as telling the CHESS scheduler to execute the interleaving that produced that bug.

Running Example

To explain how the CHESS scheduler controls the interleaving, lets look at a simple program. (This is our favorite example, you will see it again and again.)

This example involves two threads, a deposit thread that adds $100 to the balance, and a withdraw thread that deducts $100 from the balance. If the balance starts out as $100, we expect the final value to be $100. Both threads protect their accesses to the shared variable balance with a critical section. But, the withdraw thread does not hold the critical section lock for its entire computation, resulting in an ‘atomicity’ violation. The assert at the end fires if the deposit thread executes after the withdraw thread leaves the critical section but before it enters the critical section for the second time. This interleaving is shown below:

CHESS can find this bug by systematically exploring all interleavings.

Instrumentation

First, CHESS instruments the input program to make calls to the CHESS scheduler. We use various techniques to perform this instrumentation (which will not be described this blog post). This is how the code above will look after the instrumentation.

By default, CHESS instruments a call to the CHESS scheduler before every synchronization operation. In mchess, you can use the /volatile option to instrument a call before volatile accesses as well.

Inserting Delays

What does the scheduler to do at ChessSchedule() calls? The goal is to insert delays to force different interleavings. To see this, let us look at a “first-cut” solution, where the scheduler inserts random delays, as shown below:

Now, depending on how the random numbers are seeded, we are likely to get different interleavings of the two threads on each run. Convince yourselves that for particular random sleep sequences, one can emulate the interleaving that results in the bug shown above. But, there are still many problems with this solution. For instance, many (in fact, infinitely many) random sequences will result in the same interleaving, causing a wastage of test resources. Also, starting from the same random seed, you are still not guaranteed to see the same interleaving --- the Windows scheduler still decides how long a thread sleeps and when to run threads. So, repro is still a problem.

CHESS improves upon this “first-cut” solution by selectively blocking and enabling threads, in such a way that the Windows scheduler has absolutely no control. The CHESS scheduler creates a semaphore for each thread. At each call to ChessSchedule(), the calling thread queries the scheduler to see if the thread should block, and if so, the it blocks on its semaphore. Simultaneously, the scheduler releases the semaphore of the thread that needs to run next. By doing so, the scheduler is able to orchestrate an interleaving of its choice. For instance, the buggy interleaving can be achieved as follows:

Initially, the semaphore for the two threads “withSem” and “depSem” are not available. At the beginning of the program, the scheduler decides that it wants the withdraw thread to run by releasing withSem. Note, the deposit thread will block on depSem while the withdraw thread makes progress. Also, as the deposit thread is blocked, the Windows scheduler has no choice but to schedule the withdraw thread. After the withdraw thread leaves the critical section, it calls into the CHESS scheduler again (at the instrumentation before the next EnterCriticalSection). At this point, the scheduler decides to block this thread and enables the deposit thread by releasing depSem. Now, the withdraw thread blocks on its semaphore while the deposit thread makes progress. Again, as the Windows scheduler sees that the only enabled thread is the deposit thread, it has no choice but to schedule that thread.

By picking different choices at the instrumentation points, the scheduler is able to force different interleavings. Another interleaving example is shown below:

Repro is now simple. Before an execution, the scheduler dumps to disk the choices it is going to make at each ChessSchedule() call. For repro, the scheduler simply reads these choices from the disk.

There are still some intricacies involved: as the scheduler inserts artificial synchronizations with these semaphores, these can conflict with other synchronizations in the program resulting in a deadlock. Imagine, a thread holds a lock and then blocks on the semaphore that CHESS has created for that thread. Now, the CHESS scheduler schedules another thread that simply goes and blocks on the lock, we have a deadlock that CHESS introduced. While we try hard to find your bugs, we don’t want you to be chasing false bugs that we generated. The CHESS scheduler is smart enough and such deadlocks don’t happen. If you are a concurrency wizard, you probably know how hard this can be, especially when programs can use a variety of synchronizations, including spinlocks. But, as we have solved that problem, you can sleep tight and be a blissful user of CHESS :)

CHESS Release on MSDN DevLabs

CHESS Tool — Fri, 09 Jan 2009 04:07:00 GMT

Hi. This is Tom Ball. I am a Principal Researcher at Microsoft Research, where I manage the Software Reliability Research group in the Research in Software Engineering area.

On behalf of the CHESS team, I am happy to announce our first DevLabs pre-release of the CHESS tools (build 0.1.30106.5) for finding subtle concurrency errors in multithreaded single-process Windows and .NET programs.

CHESS is specifically designed for concurrency unit-testing and requires that you provide a set of test functions, each testing a particular concurrency scenario in the program. CHESS exhaustively enumerates all thread schedules of a test function by systematically inserting preemptions (unplanned interruptions of a thread) at various points in a program’s execution.

CHESS is realized as a test host for Visual Studio Team System 2008, as well as a set of command-line tools for analyzing .NET and unmanaged code. CHESS also includes a simple graphical user interface for exploring error traces of concurrent programs called Concurrency Explorer.

This post gives a glimpse of the Visual Studio Team System 2008 integration. Later posts will describe the command line tools. You can find out more about CHESS at our home page and MSDN forum.

Exploring Thread Schedules with CHESS

We provide a test host ([HostType(“Chess”)]) for Visual Studio Team System 2008 that runs managed unit tests under control of CHESS. Let’s take a quick look at a test of a bank Account class that is supposed to be thread-safe (you can find the code for Account at the end of this post):

    [TestClass]
    public class TestBank
    {
        [TestMethod]
        public void WithdrawAndDepositConcurrently()
        {
            var account = new Account(10);
            var child = new Thread(
               o => { (o as Account).Withdraw(2); }
               );
            child.Start(account);
            account.Deposit(1);
            child.Join();

            Assert.AreEqual<int>(9, account.Read());
        }
    }

The attributes [TestClass] and [TestMethod] tell Visual Studio that the class TestBank and method WithdrawAndDepositConcurrently are test code. The body of the method creates an Account instance with $10. It then creates a child thread that will withdraw $2 from the account. The main thread starts the child thread and concurrently deposits $1 in the same account and then waits for the child thread to complete. Of course, regardless of the thread schedule, we expect the account to contain $9 at the end, as asserted in the final statement. We ran this test and got the following output:

Should we be satisfied that the test passed? Our answer is “definitely not!” This is because this test has no control over which thread schedule executes. To test the code with CHESS, we simply attribute the WithdrawAndDepositConcurrently method with the HostType attribute, as shown below:

        [TestMethod]
        [HostType("Chess")]
        public void WithdrawAndDepositConcurrently()
        {

Running the test again, we see the following:

We ended up with $8 instead of $9 - not good! If we run the test again, we get exactly the same result. This is because CHESS explores thread schedules in a deterministic order. That is, CHESS does not randomly perturb the thread scheduling but instead systematically explores the thread schedules.

Reproducing a Buggy Thread Schedule with CHESS

For long running tests, the number of schedules that CHESS explores can be enormous: CHESS may explore thousands if not tens of thousands of schedules before finding an error. When CHESS does find an error, it records an ASCII representation of the thread schedule that led to the bug. With this schedule, you can use CHESS to immediately reproduce the bug without waiting through the many bug-free schedules CHESS explored to find the bug. To access the CHESS repro, we double click on the test in the above pane to see:

The “Error Message” section details the nature of the error. CHESS uses “Standard Console Output” section to give you information about the test and how to reproduce the error. The section “Standard Console Error” section contains a set of attributes that will help you reproduce the error with CHESS. We click on the link to copy this section’s content to the clipboard and then paste the contents of the clipboard before the method WithdrawAndDepositConcurrently, so the code looks like:

Note that the ChessScheduleString is in a region so you can hide it; it is not intended to be human-readable. The string contains the schedule of events in the thread schedule that caused the assertion violation. There are two new attributes to direct CHESS. The first (“ChessMode”) tells CHESS to reproduce the execution directed by the CHESS schedule string. (The other mode of CHESS is the default exploration mode in which CHESS enumerates the thread schedules.)

Debugging with CHESS

Now we will run the test under the control of the debugger, with CHESS controlling the schedule, to find the source of assertion violation. When debugging, the second attribute (“ChessBreak”) is active. This directive tells CHESS to break before each thread preemption (recall that a preemption is an unexpected context switch). CHESS has a vocabulary of concurrency primitives that you can use when debugging. As shown below, the first breakpoint takes place just before the main thread is about to acquire a lock on the Account in order to perform the deposit:

This is the spot of the first preemption which transfers control from the main thread to the child thread. We now hit F10 to jump to the next preemption, which takes place in the child thread:

The second breakpoint takes place just after the child thread has read the value of the Account into the local variable “temp” (which has value 10) but just before the child thread is about to acquire a lock on the Account in order to perform the withdrawal. The error in the code is immediately obvious, as the comment explains: there is a window of time after the read of the Account’s balance but before the withdrawal in which another thread can interrupt the child thread.

We press F10 a few times to see that control returns to the main thread which performs the deposit (raising the balance to 11 dollars):

The main thread then blocks in the call child.Join(), waiting for the child thread to continue:

We press F10 a few more times until the assignment statement of the child thread is highlighted, as shown below. Hovering over the variable “balance”, we see that the current balance is 11, reflecting the deposit of the parent thread:

Hovering over the local variable “temp”, we see that its value is the old/stale value of balance (10):

Oops! Running to completion, we will witness that the assertion fails (because Withdraw will subtract 2 from 10 to get 8). The complete code of the buggy Account class is:

    public class Account
    {
        private int balance;

        public Account(int amount)
        {
            balance = amount;
        }

        public void Withdraw(int amount)
        {
            int temp = Read();
            // oops, temp could become stale if we are
            // preempted here
            lock (this)
            {
                balance = temp - amount;
            }
        }

        public int Read()
        {
            int temp;
            lock (this)
            {
                temp = balance;
            }
            return temp;
        }

        public void Deposit(int amount)
        {
            lock (this)
            {
                balance = balance + amount;
            }
        }
    }

Don’t Stress, Test with CHESS!

Please download CHESS, try it out on your code and send us comments via our forum. Enjoy!

- Tom Ball for the CHESS Team

Welcome to the CHESS blog

CHESS Tool — Fri, 09 Jan 2009 00:06:00 GMT

CHESS is a tool from Microsoft Research that helps you better test concurrent programs. You can use CHESS to systematically drive your programs into different thread interleavings, flushing out a lot of bugs in this process. Once a bug is found, CHESS can reproduce the interleaving for tremendously improving the debugging experience.