B&S: Testing Locking

[Udham Singh]

Hello Everybody !


I am just looking for good ideas/suggestions on testing multi-threaded code. I think I have a decent locking mechnanism ready but want to test it vigorously before going any further. Is there any good literature already out there on testing deadlocks, starvation, race conditions etc.

Ofcourse personal experiences (& lessons learnt) on testing locking would be greatly appreciated.

Thanks

[mike acre]

 
import java.util.logging.*;
 
public class Tester extends Thread {
 
    private static Logger logger = Logger.getLogger("suncertify.testsuite");
 
    static DB db;
    static {
        try {
 
            db = // however you get your DB or what ever you want to test
 
        } catch(Exception e) {
            e.printStackTrace();
            System.exit(0);
        }
 

    }
 
    int count;
    int thread;
    int recordNumber;
 
    public Tester(int thrd, int cnt, int rn) {
        count = cnt;
        thread = thrd;
        recordNumber = rn;
    }
 
    public void run() {
        for (int i = 0; i < count; i++) {
            try {
                String name = thread + ":" + i + ":" + recordNumber + "</code>";
                logger.fine(name + " record about to be locked");
                long cookie = db.lock(recordNumber);
                logger.fine(name + " record locked");
                String[] fields = db.read(recordNumber);
                logger.fine(name + " record read");
                int customerID = Integer.parseInt(fields[6]);
                logger.fine(name + " " + fields[5] + ", customer id = " + customerID);
                customerID++;
                logger.fine(name + " customer id incremented: " + customerID);
                fields[6] = "" + customerID;
                db.update(recordNumber, fields, cookie);
                logger.fine(name + " record updated, about to be unlocked");
                db.unlock(recordNumber, cookie);
                logger.fine(name + " record unlocked");
            }
            catch (Exception e){
                logger.log(Level.WARNING, "", e);
            }
        }
    }
 
    public static void main(String[] args) {
 
        setupLogging(); // however you set up logging
 
        new TestRunner();
    }
 
}
 
class TestRunner {
 
    public TestRunner() {
        Tester[][] tests = new Tester[10][];
        for (int i = 0; i < tests.length; i++) {
 
            tests[i] = new Tester[31];
            for (int j = 0; j < tests[i].length; j++) {
                tests[i][j] = new Tester(i, 200, j);
            }
            try {
                for (int j = 0; j < tests[i].length; j++) {
                    Thread.currentThread().sleep(100);
                    tests[i][j].start();
                }
            } catch (InterruptedException e) {
 
                System.out.println("Unexpected InterruptedException.");
            }
        }
        System.out.println("Completed all tests.");
    }
}
 

The above code is almost identical to someone elses posted on this forum.

Notes:

1/ As the code stands it spawns 33*10 threads, this is alot, too many for most RMI implementations, if you replace db with your remote stub and use that it will probably fall over, so reduce the 10 value to 2 for RMI.

2/ The 33 value is the number of rows in your table so you need to modify that.

3/ The above code guarantees a single DB object, you may want to make sure your code guarantees this on its own, depending on your design. Simply make the db non-static to test this.

4/ The code creates a lot of logging! So use java.util.logging or reduce it, or you will likely crash your PC. Also note FINE is not logged by default, you need to do - see below

5/ Add code or manually edit file so that your customer field is equal to "0"

6/ The end result is to that every record should end up customer field == 10*200. If not something is amiss. Also check very carefully that all the other fields are not corrupted, as this code also tests your RAFWrappers thread-safety.

7/ If you don't use cookies it's a simple mod in the code above.

java.util.logging setup if you haven't used it before.
otherwise default uses flippin XML

 try {
Handler fh = new FileHandler(
nameOfFile, 0, numberOfFilesBeforeOverwrite);
fh.setFormatter(new SimpleFormatter());
Logger.getLogger("suncertify").addHandler(fh);
Logger.getLogger("suncertify").setLevel(Level.FINE);
}
catch (IOException ex) {
ex.printStackTrace();
}
 

Have fun

[peter wooster]

Originally posted by Udham Singh:
Hello Everybody !


I am just looking for good ideas/suggestions on testing multi-threaded code. I think I have a decent locking mechnanism ready but want to test it vigorously before going any further. Is there any good literature already out there on testing deadlocks, starvation, race conditions etc.

Ofcourse personal experiences (& lessons learnt) on testing locking would be greatly appreciated.

Thanks

You definitely need a multithreaded tester, such as the one Mike posted. Another thing you should do is insert random delays into (or around) your file access code. It is quite possible for locking code to appear to work perfectly when the system is very fast and fall over when it slows down, since this introduces more room for race conditions. Note that most file activity on modern systems is cached by the Operting System and runs very fast, this won't be the case over a network, or if using a conditioned OS as might happen in Sun's testing.