Difference between revisions of "FAQ.MultiThreading"
| (15 intermediate revisions by 2 users not shown) | |||
| Line 4: | Line 4: | ||
When dealing with applications that need several connections, often using threads come up. Why that ? Mainly because the idea to use (if it's a client) or to serve (if it's a server) several sockets - ie several connections - means using or serving them concurently. And, the easiest way to understand "concurently" is to say "doing several thing at the same time" and them comes up the Threads, the multitasking, etc... | When dealing with applications that need several connections, often using threads come up. Why that ? Mainly because the idea to use (if it's a client) or to serve (if it's a server) several sockets - ie several connections - means using or serving them concurently. And, the easiest way to understand "concurently" is to say "doing several thing at the same time" and them comes up the Threads, the multitasking, etc... | ||
| − | Although with ICS it's not '''primarily''' necessary, as ICS is based on the [[Asynchronous_Paradigm | Asynchronous Paradigm]], sometimes | + | Although with ICS it's not '''primarily''' necessary, as ICS is based on the [[Asynchronous_Paradigm | Asynchronous Paradigm]], sometimes threads have to be used. |
| − | But before to see why and how to use threads with ICS, let's define what '''is''' a thread : ''"Threads are a way for a program to split itself into two or more simultaneously running tasks <nowiki>[...]</nowiki> Threads are similar to processes, but differ in the way that they share resources "'' ([http://en.wikipedia.org/wiki/Thread_%28computer_science%29 Wikipedia's Thread (computer_science)]). By extension, MultiThreading is the ability for a | + | But before to see why and how to use threads with ICS, let's define what '''is''' a thread : ''"Threads are a way for a program to split itself into two or more simultaneously running tasks <nowiki>[...]</nowiki> Threads are similar to processes, but differ in the way that they share resources "'' ([http://en.wikipedia.org/wiki/Thread_%28computer_science%29 Wikipedia's Thread (computer_science)]). By extension, MultiThreading is the ability for a process to have several threads. |
| − | + | Using threads can present some advantages. Among them, there's the possibility to run different tasks at the same time, provided that the code is thread safe. Another one is the possibility to use several processor at the same time, if your system is multiprocessor based. A last one is the ability to run some lengthy process in the background, while not freezing the main application process. | |
| − | |||
| − | |||
| − | + | But there're also disadvantages in using threads. When you're using threads, you have to know that the processor will switch from thread context to another thread context. It means that it will spend some time to control the threads' switch. This "wasted switching time" will slow down your application - especially on a mono processor based system. Think of it when you prepare a multi threaded application to improve speed. Another disadvantage is the fact that if you want to access the same resource (I/O, global variable, ...) from two separate threads, you have to manage the sharing yourself - ie disabling any access to the resource if it is already accessed - and prevent yourself any [http://en.wikipedia.org/wiki/Deadlock deadlock]. Last, but not least of this little list of disadvantages, Delphi's VCL is not thread safe. Which means that you cannot use forms or buttons or whatever VCL component within a thread. | |
| − | + | ||
| − | + | So... What to do ? | |
== The Main Question == | == The Main Question == | ||
Do i need Threads ? | Do i need Threads ? | ||
| − | + | ||
| + | Or, practically, how to determine the use of threads ? As mentioned earlier, ICS is based on the [[Asynchronous Paradigm]]. It means that if you plan to use threads just because there'll be several <!-- there should be here an estimation of possible concurrent connections possible within one process --> '''simultaneous''' sockets/connections, this is '''definitely''' not needed. By the same way, if you plan to use one thread per connection because you think that '''TCP/IP sockets I/O are blocking''' and that you don't want the main process to be frozen because of a I/O waiting state, again, it's not needed at all, still because of the Asynchronous model used by ICS. | ||
| + | |||
| + | But, there're situations where using threads may be very useful : | ||
| + | * you have a listening TCP/IP server that receives data in the background, and you want to isolate it from the main process ; | ||
| + | * you have written a server application and you want to be able to handle hundred thousands connections at the same time. For such amount of simultaneous connection, you should use some multi processor based system, and then write your application in a way to share the connections load between the processors ; | ||
| + | * you're application has to do some job that may take time - some SQL queries on a RDBMS, getting data from a slow I/O port. To prevent the main process to be blocked - or "frozen" - while this lengthy operation, you can delegate this operation execution within a thread. When the thread is finished, then you can display the result - or send it back. | ||
== A Thread per Socket == | == A Thread per Socket == | ||
| Line 28: | Line 32: | ||
== A Worker Thread == | == A Worker Thread == | ||
When running a lengthy process (SQLing a RBDMS, doing bottlenecked I/O, ...), and to prevent GUI from freezing, encapsulating it in a thread (JobThread), and sending back data when the thread is done (or simulating a process end). | When running a lengthy process (SQLing a RBDMS, doing bottlenecked I/O, ...), and to prevent GUI from freezing, encapsulating it in a thread (JobThread), and sending back data when the thread is done (or simulating a process end). | ||
| + | |||
| + | == See Also == | ||
| + | {| | ||
| + | |- | ||
| + | | width="200" |[http://en.wikipedia.org/wiki/Thread_%28computer_science%29 Wikipedia's Thread (computer_science)] |||| Article from Wikipedia about threads. Read the related links also ! | ||
| + | |- | ||
| + | | width="200" |[http://www.eonclash.com/Tutorials/Multithreading/MartinHarvey1.1/ToC.html Multithreading - The Delphi Way] |||| A good article, with sources, about how to use threads in Delphi | ||
| + | |} | ||
Latest revision as of 17:28, 19 November 2007
Main page -> FAQ -> MultiThreading
Contents
Introduction
When dealing with applications that need several connections, often using threads come up. Why that ? Mainly because the idea to use (if it's a client) or to serve (if it's a server) several sockets - ie several connections - means using or serving them concurently. And, the easiest way to understand "concurently" is to say "doing several thing at the same time" and them comes up the Threads, the multitasking, etc...
Although with ICS it's not primarily necessary, as ICS is based on the Asynchronous Paradigm, sometimes threads have to be used.
But before to see why and how to use threads with ICS, let's define what is a thread : "Threads are a way for a program to split itself into two or more simultaneously running tasks [...] Threads are similar to processes, but differ in the way that they share resources " (Wikipedia's Thread (computer_science)). By extension, MultiThreading is the ability for a process to have several threads.
Using threads can present some advantages. Among them, there's the possibility to run different tasks at the same time, provided that the code is thread safe. Another one is the possibility to use several processor at the same time, if your system is multiprocessor based. A last one is the ability to run some lengthy process in the background, while not freezing the main application process.
But there're also disadvantages in using threads. When you're using threads, you have to know that the processor will switch from thread context to another thread context. It means that it will spend some time to control the threads' switch. This "wasted switching time" will slow down your application - especially on a mono processor based system. Think of it when you prepare a multi threaded application to improve speed. Another disadvantage is the fact that if you want to access the same resource (I/O, global variable, ...) from two separate threads, you have to manage the sharing yourself - ie disabling any access to the resource if it is already accessed - and prevent yourself any deadlock. Last, but not least of this little list of disadvantages, Delphi's VCL is not thread safe. Which means that you cannot use forms or buttons or whatever VCL component within a thread.
So... What to do ?
The Main Question
Do i need Threads ?
Or, practically, how to determine the use of threads ? As mentioned earlier, ICS is based on the Asynchronous Paradigm. It means that if you plan to use threads just because there'll be several simultaneous sockets/connections, this is definitely not needed. By the same way, if you plan to use one thread per connection because you think that TCP/IP sockets I/O are blocking and that you don't want the main process to be frozen because of a I/O waiting state, again, it's not needed at all, still because of the Asynchronous model used by ICS.
But, there're situations where using threads may be very useful :
- you have a listening TCP/IP server that receives data in the background, and you want to isolate it from the main process ;
- you have written a server application and you want to be able to handle hundred thousands connections at the same time. For such amount of simultaneous connection, you should use some multi processor based system, and then write your application in a way to share the connections load between the processors ;
- you're application has to do some job that may take time - some SQL queries on a RDBMS, getting data from a slow I/O port. To prevent the main process to be blocked - or "frozen" - while this lengthy operation, you can delegate this operation execution within a thread. When the thread is finished, then you can display the result - or send it back.
A Thread per Socket
When incoming connection, encapsulating socket within a thread, and managing communication within the thread, across several threads
Many sockets per thread
A single thread is able to handle a lot of simultaneous sockets. Using a single socket per thread is not the way to go to support a large number of concurrent connections. In that case you need to use many socket per threads. Something like 10 to 500 sockets per thread. This way you can handle thousand simultaneous connections.
A Worker Thread
When running a lengthy process (SQLing a RBDMS, doing bottlenecked I/O, ...), and to prevent GUI from freezing, encapsulating it in a thread (JobThread), and sending back data when the thread is done (or simulating a process end).
See Also
| Wikipedia's Thread (computer_science) | Article from Wikipedia about threads. Read the related links also ! | |
| Multithreading - The Delphi Way | A good article, with sources, about how to use threads in Delphi |
