Multi-Threading and Multiple/Single Core CPUs

[sunama]

I am currently in the process of building a new application.

For the first time, I'm making extensive use of multithreading.

What I find is when I run the following subroutines without multithreading:

Sub1
Sub2
Sub3

...all sequentially (on my dual core cpu computer), the program itself grinds to a halt and becomes completely unresponsive, until the 3 subroutines have all completed their work.

However, when I assign those same 3 subroutines to 3 separate threads and then run those threads simultaneously, the program is responsive and if I hadnt programmed the application myself, I would never know that the program is actually "working" hard, in the background. The finish time of the subroutines is also faster.

Now, I am using a Core2Duo. So, when running a multithreaded program, it is logical to expect the program to run faster, compared to if an identical program is run, which is not equipped to deal with multithreading. In fact, this is what I have found above.

Q1. Would running a multithreaded program, on an older cpu, which has no HyperThreading and only a single logical cpu, allow the program to be run without making it completely unresponsive (which proved to be the case when using a multi core cpu), until the 3 subroutines have completed their work.

Q2. Would using a multi threaded application on a computer with a single logical cpu be a problem?

I ask this because I want the program to be run on older computers, PDAs and smartphones, which won't have multi core cpus.

 

[sunama]

Sorry, I should've been a little clearer.

I've edited the original post.

Basically, when I run the program without multithreading (on my dual core cpu computer), only the program itself grinds to a halt and becomes completely unresponsive, until the 3 subroutines have all completed their work.

When I run those 3 subroutines, using threads, the program is responsive and if I hadnt programmed the application myself, I would never know that the program is actually "working", in the background.

 

[sunama]

I'm guessing this is running on Windows?

Correct

If so, it sounds like you're simply executing the subroutines on the UI thread.

Correct.

Without getting too into the details in Windows applications there is a loop whose job is to continuously process Windows messages, this runs on the main thread that the application starts on - this is known as the UI thread.

When your subroutines execute, if they are on that thread then the message loop can't process messages as that thread is busy running stuff in your subroutines, hence why the UI appears to lock up.
When the subroutine finishes the message loop continues processing any messages that have been put into its queue and the UI responds again.

So, if you can use another thread to do the processing the UI thread can happily go on processing messages, the UI remains responsive and the logic gets processed separately.
Obviously if you have a multi-core CPU then the subroutines will generally get processed using a separate physical core on the CPU, but even on a single core CPU this type of thing has a massive benefit.

Even if you can't process two things at once Windows will use context switching to enable the single core to process the messages in a timely fashion and then process the stuff in your subroutines without having the UI lock up.

Well explained. Thanks.

NathanE: thanks for your explanation. I'm very new to multithreading and only started playing around with this a few days ago, discovering in the process that my program seems to run more smoothly when using threads. Until now, all the threads whcih I've created have been my own (not threadpool), but I shall experiment with the threadpool later on today. In all fairness, I don't think I will bother using threads for small (2s-3s) tasks. Using the threadpool seems to have problems all of its own, which I want to avoid. I always aim to keep the program as simple as possible, even if there is a "slight" performance hit. It makes it easier when it comes to debugging and developing the program further.

 

[sunama]

The application I'm working on at work at the moment has what I can only describe as thread diarrhoea because lots of the developers seem to have thought: using lots of threads = good and will make the application faster and more responsive.

Thats exactly what I want to avoid doing - adding threads, just for the sake of it. If possible, I would prefer to use as few threads as possible, to avoid other problems further down the line which could result in hours/days lost in debugging.

Out of interest what language are you coding in?

VB.net, but if the application proves successful, then I will have to re-code it in other languages.

 

[sunama]

PS: Never spawn your own threads unless you're absolutely certain you need to. Use a thread pool in 95% of cases.

In total, I manually created 13 of my own threads. It takes roughly 3.5s for those 13 threads to complete their tasks.

I then played with the threadpool and rather than creating my own threads, I used the threadpool. The same operation took 18.5s.

I'm not saying that my testing is definitive, but I can already see that using the threadpool isn't always the best way to get the job done.

 

[sunama]

I was playing around with .net and threads today.

... I wanted to pass a method with parameters in to run on the new thread (wasn't available for thread pool threads iirc? at the time).

Is this something that can be done in the thread pool, ...

There is a way of passing parameters using threads (both making your own threads and using the threadpool). We do this by:
creating a class (which includes properties and a sub/method).
then creating an object of that class, passing the parameters, as well
then creating the thread - after 'address of' we state the name of object, followed by the name of the method.

This worked for me, however, things got a little complicated when I needed to create multiple objects of that class and multiple threads, using those objects. At this moment I realised that should I ever need to debug, passing parameters into threads, using the above technique could prove extremely difficult.

Based on what I experienced today, I won't be passing parameters into threads, unless it is absolutely necessary and there is no other way around it.

 

[sunama]

Something really doesn't sound right with that, the ThreadPool definitely shouldn't take that much longer than creating your own threads.
Do you have a code sample that you can post up?

I could. The only problem is that the code is very very long and I wouldn't want to bore you guys with the functions/subs being called.

What I will say is that the functions being called relate to loading of data from txt files, line by line.

Creating my own threads seems faster to achieve this. I spent a few hours last night switching from Threadpool and spawning. For smaller operations which take less than 1s, there is very little in it. But once the operation gets longer/bigger the thread spawning seemed to be the way to go.

In some instances, I've avoided threads altogether as simply calling functions (without linking a thread to it), worked faster.

I've also taken the advice of moving the GUI out on its own thread, which has worked a treat.

In summary, I have a situation where the GUI/Form loads up within 1-2s and is responsive thereafter, while the start-up routines (courtesy of multithreading) are loaded up within the following 3-5s. That'll do me fine.