Lisp
asked on
Single Threading Vs MultiThreading
When should I use single threading over multithreading and vice versa?
I understand the performance issues caused the the need for marhaling while using both single and multithreading but not when I should choose one over the other outside of this.
I understand the performance issues caused the the need for marhaling while using both single and multithreading but not when I should choose one over the other outside of this.
ASKER
OK but can you give me an example of such a big need? The question was asking when do I need to use each of these. I am attempting to prepare for an exam and need to know the answer.
Thanks.
Thanks.
This is not really a VB issue as it applies to any language. So if you were asking, “why would you want to use multi-threaded tasks?” there are hundreds of examples. In simple terms: “multithreading should be used to increase throughput.”
Here are the issues to consider:
1) Handling of a multithreaded environment requires additional processing and storage resources. If a task can complete in less time than the management overhead of the multithreading then throughput would be reduced. In otherworlds don’t use a sledgehammer to crack a nut.
2) Multithreading should be considered to reduce bottlenecks where slow processes are linking to faster processes.
3) There are always exceptions to every rule.
4) The multithreading control should always be aware of its processing limitations (or bandwidth limitations).
5) Multithreading can take better take advantage of resource pools so a slow process can be re-tasked to a different server.
Examples:
1) Bulk Email – Use Multi-threading
A bulk email program can send an email every six seconds. But when it hits an address where the responding server is slow or just not there, network retires could mean that it could take 30 seconds to decide that and address was bad. By multi-threading the process better throughput can be achieved. But the cute trick is to monitor the bandwidth so before opening up another thread the thread management should ping an up-line gateway to gauge the response time. If the response is greater than a preset limit the management should reduce currently operating threads. So by running perhaps 20 threads you could send perhaps 3 emails per second and the odd slow connection would not stop the ball rolling. The exception - in a LAN environment, where all recipients are local, a multi-threading bulk email may not be so desirable as it may bring the entire LAN to a standstill until the job was complete.
2) Web Server – Use Multi-threading
Reading from a resource is an ideal case for multi-threading.
3) Record Updates – Caution
In a data update situation there is a much more reduced case for multithreading as each thread needs a one-to-one relationship with the resource. Lock the data – update the record – free the lock.
Hope this helps…..
P.S. In VB you can achieve multi-threading in VB6 by using separate exe processes, controlled by a process control exe. But VB6 is not so good for creating com+ services that run on a server, in this case to would need to use C++ or VB.Net.
Here are the issues to consider:
1) Handling of a multithreaded environment requires additional processing and storage resources. If a task can complete in less time than the management overhead of the multithreading then throughput would be reduced. In otherworlds don’t use a sledgehammer to crack a nut.
2) Multithreading should be considered to reduce bottlenecks where slow processes are linking to faster processes.
3) There are always exceptions to every rule.
4) The multithreading control should always be aware of its processing limitations (or bandwidth limitations).
5) Multithreading can take better take advantage of resource pools so a slow process can be re-tasked to a different server.
Examples:
1) Bulk Email – Use Multi-threading
A bulk email program can send an email every six seconds. But when it hits an address where the responding server is slow or just not there, network retires could mean that it could take 30 seconds to decide that and address was bad. By multi-threading the process better throughput can be achieved. But the cute trick is to monitor the bandwidth so before opening up another thread the thread management should ping an up-line gateway to gauge the response time. If the response is greater than a preset limit the management should reduce currently operating threads. So by running perhaps 20 threads you could send perhaps 3 emails per second and the odd slow connection would not stop the ball rolling. The exception - in a LAN environment, where all recipients are local, a multi-threading bulk email may not be so desirable as it may bring the entire LAN to a standstill until the job was complete.
2) Web Server – Use Multi-threading
Reading from a resource is an ideal case for multi-threading.
3) Record Updates – Caution
In a data update situation there is a much more reduced case for multithreading as each thread needs a one-to-one relationship with the resource. Lock the data – update the record – free the lock.
Hope this helps…..
P.S. In VB you can achieve multi-threading in VB6 by using separate exe processes, controlled by a process control exe. But VB6 is not so good for creating com+ services that run on a server, in this case to would need to use C++ or VB.Net.
listening
ASKER
Thanks InTheDark. The points are yours. For an extra 100 points will you consider answering this for me?
If I have an application that has multiple add-ins connecting to it should the core application be multi-threaded?
Should the addins also be multithreaded to avoid marshaling or will I achieve a 1 to many relationship between add-ins and the core program by processing the addins in a single threadspace withing the core application if I have single threaded add-ins accompanied by a mulithreaded core program?
If I have an application that has multiple add-ins connecting to it should the core application be multi-threaded?
Should the addins also be multithreaded to avoid marshaling or will I achieve a 1 to many relationship between add-ins and the core program by processing the addins in a single threadspace withing the core application if I have single threaded add-ins accompanied by a mulithreaded core program?
>If I have an application that has multiple add-ins connecting to it should the core application be multi-threaded?
Again this depends on the task. Suggest you start by following these links, then we can discuss them later:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q243548
http://www.desaware.com/articles/threadingL3.htm
Again this depends on the task. Suggest you start by following these links, then we can discuss them later:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q243548
http://www.desaware.com/articles/threadingL3.htm
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>Should the addins also be multithreaded to avoid marshaling
If you read the dessaware article I think that it proposes that marshaling takes place when an object is defined on one thread but passed to another thread. Before the object can be processed the calling thread has to halt the first source thread, pass orver the parameters, execute the function, then copy the results/object back to the calling thread.
If you read the dessaware article I think that it proposes that marshaling takes place when an object is defined on one thread but passed to another thread. Before the object can be processed the calling thread has to halt the first source thread, pass orver the parameters, execute the function, then copy the results/object back to the calling thread.
Therefore, unless you have a very special need that will make it worth the big effort - you should use single threading.