Difference between revisions of "FAQ.MultiThreading"

From Overbyte
Jump to navigation Jump to search
 
(11 intermediate revisions by 2 users not shown)
Line 6: Line 6:
 
Although with ICS it's not '''primarily''' necessary, as ICS is based on the [[Asynchronous_Paradigm | Asynchronous Paradigm]], sometimes threads have to be used.
 
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 processus to have several Threads.
+
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.
  
* Advantages :
+
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.
** run concurently with other threads if the code is thread safe
 
** the ability to use several processor
 
  
* Disadvantages
+
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.
** resources sharing has to be managed carefully (concurent access)
+
 
** With Delphi, VCL - ie all the GUI stuff - is not Thread safe.
+
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 on 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.
+
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 :
 
But, there're situations where using threads may be very useful :
* the number of concurrent connections (I/O) is too high for a single processor and then you need to use several processors ;
+
* you have a listening TCP/IP server that receives data in the background, and you want  to isolate it from the main process ;
* some job needs to be done during a connection (ie getting data from a COM port, building an HTML page with a SQL query result) and may be lengthy or blocking and would '''freeze''' the main - GUI - process which has to wait for the job to be done before serving any other connection ;
+
* 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.
Cases where needed and where not needed
 
  
 
== A Thread per Socket ==  
 
== A Thread per Socket ==  
Line 35: 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

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