Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Thread (computing)
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===Multithreaded programs vs single-threaded programs pros and cons=== Multithreaded applications have the following advantages vs single-threaded ones: * ''Responsiveness'': multithreading can allow an application to remain responsive to input. In a one-thread program, if the main execution thread blocks on a long-running task, the entire application can appear to freeze. By moving such long-running tasks to a ''worker thread'' that runs concurrently with the main execution thread, it is possible for the application to remain responsive to user input while executing tasks in the background. On the other hand, in most cases multithreading is not the only way to keep a program responsive, with [[non-blocking I/O]] and/or [[Unix signals]] being available for obtaining similar results.<ref>{{Cite journal |first=Sergey |last=Ignatchenko |title=Single-Threading: Back to the Future? |url=http://accu.org/index.php/journals/1634 |journal=[[Overload (magazine)|Overload]] |issue=97 |pages=16β19 |date=August 2010 |publisher=[[ACCU (organisation)|ACCU]]}}</ref> * ''Parallelization'': applications looking to use multicore or multi-CPU systems can use multithreading to split data and tasks into parallel subtasks and let the underlying architecture manage how the threads run, either concurrently on one core or in parallel on multiple cores. GPU computing environments like [[CUDA]] and [[OpenCL]] use the multithreading model where dozens to hundreds of threads run in [[Data parallelism|parallel across data]] on a [[Manycore processor|large number of cores]]. This, in turn, enables better system utilization, and (provided that synchronization costs don't eat the benefits up), can provide faster program execution. Multithreaded applications have the following drawbacks: * ''[[#Synchronization|Synchronization]]'' complexity and related bugs: when using shared resources typical for threaded programs, the [[programmer]] must be careful to avoid [[Race condition#Computing|race conditions]] and other non-intuitive behaviors. In order for data to be correctly manipulated, threads will often need to [[Rendezvous problem|rendezvous]] in time in order to process the data in the correct order. Threads may also require [[mutual exclusion|mutually exclusive]] operations (often implemented using [[lock (computer science)|mutexes]]) to prevent common data from being read or overwritten in one thread while being modified by another. Careless use of such primitives can lead to [[deadlock (computer science)|deadlock]]s, livelocks or [[race condition|races]] over resources. As [[Edward A. Lee]] has written: "Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly non-deterministic, and the job of the programmer becomes one of pruning that nondeterminism."<ref name="Lee" /> * ''Being untestable''. In general, multithreaded programs are non-deterministic, and as a result, are untestable. In other words, a multithreaded program can easily have bugs which never manifest on a test system, manifesting only in production.<ref>{{Cite journal |title=Multi-threading at Business-logic Level is Considered Harmful |url=https://accu.org/journals/overload/23/128/ignatchenko_2134/ |first=Sergey |last=Ignatchenko |journal=[[Overload (magazine)|Overload]] |issue=128 |pages=4β7 |date=August 2015 |publisher=[[ACCU (organisation)|ACCU]]}}</ref><ref name="Lee">{{Cite web |first=Edward |last=Lee |date=January 10, 2006 |title=The Problem with Threads |url=http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html |publisher=UC Berkeley}}</ref> This can be alleviated by restricting inter-thread communications to certain well-defined patterns (such as message-passing). * ''Synchronization costs''. As thread context switch on modern CPUs can cost up to 1 million CPU cycles,<ref>{{Cite web |author='No Bugs' Hare |date=12 September 2016 |title=Operation Costs in CPU Clock Cycles |url=http://ithare.com/infographics-operation-costs-in-cpu-clock-cycles/}}</ref> it makes writing efficient multithreading programs difficult. In particular, special attention has to be paid to avoid inter-thread synchronization from being too frequent.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)