标签: multithreading

Dear Readers,   In the last article, we saw how the semiconductor industry has hit the wall in increasing the CPU speeds and how the onus of performance improvements is getting shifted to software community. In this article, let us see difficulties for software folks in taking advantage of the multiple cores.   If a CPU has a single core, there is only one unit of execution. But if we have more than one core and if the software has to use them effectively, then software has to move to concurrent programming model.   What this means is that software should be broken into multiple pieces of code which work independently. Each of the unit of the code is run as a thread of execution .   Let us take an example. A terminal emulator program has to poll keyboard, serial port and display the inputs it receives from the two ports. In a concurrent program, we can have a thread to read from serial port, another for keyboard input and third one can put the inputs on the screen. These threads talk to each other through shared data structures or messages.   Though this seems simple, there are issues if we go deeper!   Firstly , concurrent programming is quite different to the programming paradigm that software community is used to till now. In a single core model, the code is fetched from memory, decoded and executed by the CPU. There are no temporal dependencies. If we have more than one core, then each of the cores can execute the code in parallel giving raise to many possibilities. When two or more threads access a piece of data, there is always a chance of wrong sequencing of access and thereby creating a race condition. To prevent the race conditions, the programmers are expected to lock the access to the shared resource with a semaphore or a lock. But concurrent programming is prone to errors and can cause deadlocks in system. It is difficult for someone to qualify that multithreaded application does not have any deadlocks. Many programmers have not used the concurrent programming models, its constructs in their work and it takes time to understand the nuances of it before a programmer can be productive.   Secondly , it is difficult to visualize the interplay of threads of execution after the number of threads goes beyond two or three threads. The complexities of order of access and sequence increase exponentially and it is difficult for the human mind to think in parallel. Programmer can make mistakes in design and coding when she is into concurrent programming. These mistakes are over and above the normal programming mistakes that a programmer makes in the logic!!   Finally , there is an issue of confidence in the code. With the introduction of multiple threads and concurrency, there is definitely a chance of introducing errors. When a program is executed sequentially, certain assumptions are taken for granted. The most important of these being that the code will execute in the order presented in the program. Once the program is split across cores, this assumption is no longer valid. Many times, a bug could be reported but it cannot be reproduced in the lab as it is difficult to know the sequence of interplay of threads and locks that created the issue. There have been cases where bugs were sleeping for years before they were found in the code!   If concurrent programming is difficult, is it not getting used in the industry at all? It is not true. It has existed for long and is popular in some segments. The difference is that concurrent programming is moving to mainstream from being niche!   In the next article, let us see where concurrent programming is used. Meanwhile, I look forward to your valuable feedbacks!