A thread in a Java program runs asynchronously as a independent path of execution. It is basically a subset of code designed to execute simultaneously in sync with other subsets of the same program. The motivation behind threading is to leverage concurrency. But, the problem is that the programs that work with parallel logic are not only difficult to conceptualize but also difficult to implement consistently. Even if we devise logic to work in a parallel mode, we cannot be sure about its consistency. Concurrent execution of code raises numerous issues such as synchronization, dead-locks, atomicity, resource sharing, and so forth. This article is a slightly detoured exploration of threads in general and the Java thread model in particular.
Operating systems evolved to run more than one process at once. These processes execute in an isolated, independent manner to which resources are allocated such as memory, file handles, and security credentials. On occasion, one process communicates with another through a communication mechanism such as sockets, signals, shared memory, semaphores, and files. A thread is also very similar to a process but works on a smaller scale, sometime called a lightweight process. It makes multiple streams of program control flow to coexist within a process.
A normal Java code executes in a sequential manner. When we apply the mechanism of threading, we are actually applying a tweak to an otherwise straightforward sequential model of programming. This tweak bifurcates (read n-bifurcate) the code to work in a concurrent environment where each execution path is called a thread. In a multi-threading environment, it must be ensured that one thread must be executed in isolation and independent of other threads to minimize dependency, because dependency may halt the execution completely. Sometimes, two or more resources compete for a resource. This may lead to a race condition or a dead-lock. To overcome such a situation, we can grossly think of two ideas:
Problems with multi-programming can be quite damaging if not synchronized. An isolated execution of thread is an ideal situation, but in practice inter-communication between threads is a necessity, especially when one thread needs a resource used by another thread. In such a case, the requesting thread must be gentleman enough to wait for the release of resource used by another thread.
In a imperative programming language such as Java, it is not so easy to create a parallel logic without closely considering the issue of thread safety, because it is not an inherent principle of language design. The code must be designed in a thread-safe manner, explicitly. There are no strict rules to ensure safety of thread, but considering the following pointers may help create one.
The problem with multi-threaded programming is that it gives the power of concurrency and ruin at the same time. If we invite the mechanism of threading, we cannot ignore its pitfalls. It is very difficult to create a deadlock in a pure functional language like Haskell.
