The concept of thread programming can be a disaster if the programmer does not consider certain constructs, namely, thread safety, deadlocks, and starvation.
While it is simple to write a program that uses multiple threads to perform a job, it is extremely difficult to write a program that guarantees the job is performed well and without errors. Often the case, multi-threading can lead to deadlocks, that is no thread can advance, while other threads may be starved waiting.
There are many uses to making a program multi-threaded. For example, a webserver that needs to handle multiple requests can be multi-threaded to handle simultaneous requests. This works well if the machine is multi-cored, so each core can be busy operating. This may not work as well if there are too many executing threads, since context switching, the act of saving the current thread's execution and resuming the execution of another thread, is expensive.
But there are many advantages for a multi-threaded program. It can increase resource utilization and throughput. Also, it can load share between mulitple core machines.
Thread safety is important, especially, when threads share a global resource, often the case, a lock. If a thread accesses a shared resource, another thread should not be accessing that same resource at the same time, unless all simultaneous operations are read. If any one of the operations is a write, an unexpected result may occur. These important sharing sections is normally protected with locks and called the "critical section." Furthermore, even if these critical sections are safely guarded, one thread may have changed a shared resource that another thread does not expect.
Multithreaded programs can always cause debugging annoyances because context switching can occur at any time, thus repeating an issue is not often possible. Race conditions may dynamically change the program behaviour unexpectedly as well.
Deadlock is another important multi-threaded issue. A deadlock occurs if all of the following four conditions hold true: a thread is holding a resource, there is no preemption, there is a circular wait dependency, and the resource that is being waited on is held by a thread stuck in the circular dependency.
Deadlocks can be prevented, or resolved. To resolve a deadklock, simply reset each thread that is stuck, either by revoking the shared resource, preemption, or terminating a thread and restarting it again. On the other hand, preventing deadlocks can be challenging. Sophisticated algorithms are available, which is beyond the scope of this article.
FPvnKj Im thankful for the blog.Thanks Again. Fantastic.
wow, awesome article post.Much thanks again. Really Cool.
Major thanks for the article post.Really thank you! Really Cool.
Thanks for sharing, this is a fantastic blog article.Thanks Again. Keep writing.
I am so grateful for your article post.Thanks Again. Fantastic.