Creating multithreaded programs can seem challenging at first. We help you sort through the problems and point you on the path to finding the solutions.
Concurrent programming has been around for a long time. Programmers have typically used threads to express concurrency. Mapping independent tasks to threads gives the operating system greater flexibility in scheduling, which helps hide program latency. While one thread waits for data, the operating system can run another. In addition, most systems are capable of doing computation and I/O simultaneously, provided that computation and I/O are independent tasks mapped to threads. With symmetric multiprocessors (SMP) becoming more common, programmers are starting to use threads to take advantage of the performance benefits of parallel computing. (For an introduction to threads and their uses, see the four-part “Compile Time” series mentioned in the Resources box.)
Concurrency adds a temporal component to coding that can be confusing at first. It also makes debugging harder because errors can be difficult to reproduce. Fortunately, the same types of errors tend to appear over and over again. This article will try to show you what not to do, hopefully avoiding bugs in the first place (or at least making it easier to spot errors in existing programs). The concurrent programming errors described in this article are divided into two categories — those causing data races and those causing deadlock. Most of the example programs sometimes execute correctly and sometimes don’t. That’s the difficulty of debugging concurrent programs. Multithreaded programs that work fine during testing often fail in the hands of the end-user.
In this article, each listing that contains an error is denoted as…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
