Areas to test for multithreaded applications

Testing is key to the process of verifying the correctness of a multithreaded program.

You must consider the following key concepts when testing a multithreaded program:
  • Multiple instances

    Test your multithreaded program by having multiple instances of the program active at the same time. If your application allows the number of threads to vary, configure each instance of the program with a different number of threads.

  • Varying system workload

    Test your multithreaded program by running it repeatedly with a different mix of applications running. The interaction of different applications might reveal timing problems or race conditions.

  • Stressful environments

    Environments running stressful workload can reveal contention, timing, and performance problems.

  • Different hardware models

    Whenever possible, run your multithreaded program on different hardware models with varying workload and stress levels. Different hardware models, especially multiprocessor systems, reveal a variety of problems. If you are porting an application from another platform, verify that your application produces the same result on both platforms.

Testing is only one consideration for validating the correctness of a multithreaded program. Code inspections are critical and often the only way to determine potential problems. When inspecting the code for a multithreaded program, you need to continually ask this question, "If the code is interrupted at this point, what potential problems can occur?" Often, knowing the potential sources of problems helps you avoid them. Common problems are as follows:
  • Hardware-related problems

    It is typically sufficient to test a single-threaded program on one hardware model and expect that it will behave identically on different hardware models. Unlike single-threaded programs, you cannot have the same expectation for a multithreaded program that runs on a hardware platform that supports kernel threads. On these platforms, each thread runs in a separately dispatched task. Depending on the processor speed, main memory sizes, storage capacity, and other hardware characteristics, timing problems or race conditions might occur when the multithreaded programs are called on different hardware. Multiprocessor systems further increase the likelihood of discovering potential problems. On multiprocessor systems, two different threads can run the same sequence of code at the same time.

  • Java™ virtual machine implementation problems

    A problem for Java application developers is the implementation of the Java virtual machine (JVM). On some platforms, the JVM is single-threaded. On the IBM® i operating system, the JVM is multithreaded. Similar problems might occur with a Java application as with an application from another platform that supports user threads.

  • Threads model problems

    If you are porting an application from another platform, you must know the threads model that the other platform supports. If the other platform supports a user threads model, you might encounter problems with the application on IBM i because IBM i supports a kernel threads model. A key difference between the two models is that the user threads model uses cooperative scheduling, whereas the kernel threads model uses preemptive scheduling. With a user threads model, only one thread in the application can be active at a given time. With a kernel threads model, the machine determines which threads are eligible to run. Race conditions, resource contention, and other problems might occur with kernel threads on IBM i, because the application writer did not consider these potential problems when using user threads.