Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Multiple Queries - Multithread?

Status
Not open for further replies.

jennuhw

MIS
Apr 18, 2001
426
US
I have several queries that are ran on button click. From what I have read on multithreading is that the processes don't necessarily run at the same time if I understood this correctly. I need to speed up the response times of the queries and am wondering if multithreading is the way to go. Thanks.
 
Multi-threading will allow VB to run the queries at the same time and will also make the user interface more responsive while the queries are running. It will not have any effect on the speed of the individual queries.


Hope this helps.

[vampire][bat]
 
I knew that it wouldn't make the individual queries run faster. I must have misread something. Looks like multithreading is the way to go.
 
Processes (actually threads, processes are basically areas of memory whereas threads are what do the work) don't usually "run at the same time" because a processor can only handle one instruction at a time. (The only way to have them actually run simultaneously is to have more than one processor in the system.) What actually happens is that a processor allocates "time slices" to each working thread in the system, which gives the impression of simultaneous operation.

You're probably aware that threads have "priorities" as well, which gives them higher or lower priority with the processor's time in comparison to one another. This of course implies that threads don't actually run simultaneously on a single processor.

On multiprocessor systems, you can indeed have threads running at the same time. You may remember the "math coprocessor" days; chips such as the 80286 had an optional coprocessor that would handle math calcuations on a separate thread while the main processor was doing other stuff. Many current boxes (check Dell servers for some examples) have multiple processors.

I hope this clarifies a bit.

As for multithreading, I would be VERY careful. This is NOT a step to take lightly, for there are many issues that you will need to be well acquainted with prior to starting. I'll quote from Balena's "Programming Microsoft Visual Basic.Net" (Microsoft Press, 2002, I believe there's a new edition out):
The main problem with threads is that thye can compete for shared resources, where a resouorce can be as simple as a variable or a scomplex as a database connection or a hardware device. You must synchronize access to such resources--otherwise, you can get into trouble...Visual Basic.Net provices the SyncLock construct to help you deal with these problems, and the runtime offers several synchronization objects. The key to effective multithreading is learning how to use these features properly.

That should give you an idea of what you're getting into!

HTH

Bob
 
Yep it will speed up the processing since the queries will start sooner BUT you must be carefull. Like Bob said two queries could be trying to update the same table and since you don't really know when wich thread will execute you don't know if it will happen in the right order. But if you don't try you will never know.

Christiaan Baes
Belgium

"My new site" - Me
 
You might also check into asynchronous processing. This way, you can run the queries in the background (each in its own process, ergo each on its own thread), and have the UI get notified when the query is done. Although this won't make it run faster, it will seem faster to the user as the time will go by quicker.

Bob
 
BobRodes said:
Many current boxes (check Dell servers for some examples) have multiple processors.
Or the new dual-core CPUs. Hyperthreaded processors are sort-of dual CPU, but nothing beats a true multi-processor machine for smoothness. Love them.

Like everyone else says - threading will solve at least some of your performance problems, but you have to be VERY CAREFUL, otherwise you introduce hard-to-duplicate problems. Generally, it's best to add the concept of threads at the design stage of your application. Adding them at implementation time will likely cause problems.

Rule #1 for threading: If it's not on your local stackframe (local variable or passed in as a parameter), you must protect access with a lock.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
 
lol
it will seem faster to the user as the time will go by quicker.
You're way too quick on the update Chrissie.
Bob...thats gotta be one of the best quotes of all time.

Sweep
...if it works, you know the rest..
Always remember that Google is your friend

curse.gif
 
Well. I can see that my quote sounds either naive or cynical, and I can see why it's amusing therefore. However, perceived overhead is a stronger criterion for architectural decisions than actual overhead. For example, if you put overhead at the beginning of a program, it often is more acceptable to a user than sprinkling it over different phases of the program's execution. So, glad I made everyone laugh, but even so this is a very important consideration with respect to assignment of overhead in my book.

As for you, Christiaan, you may be interested in a book by Gotswami called "The Self Aware Universe", which shows interesting evidence that physics experiments are affected by the expectations of the experimenters. Perhaps Einstein has been turning over in his grave since that was published, and perhaps he always suspected it was true and didn't want to say anything in his lifetime since it might cause his other theories to lose credibility.

Bob
 
Yes I agree (and so will einstein) that the perception of time can change but time itself will never change (a second is still a second). Perhaps 8 hour workdays might seem longer then 8 hour weekends but in the end it still is 8 hours. Einsteins calculations proved that if you travel at the speed of light then time would be different for the observer. But since we have never travelled at the speed of light (yet) it would be difficult to check that

But like all theories some of it is true and some of it is not.

I think your quote should have been

it will seem faster to the user as the time will seem to go by quicker.

But we are talking semantics here.


Christiaan Baes
Belgium

"My new site" - Me
 
<it would be difficult to check that
If I'm not mistaken, Einstein proved his theories by using them to explain an anomaly in Mercury's relationship to the earth, as predicted by Newtonian physics.

<the perception of time can change but time itself will never change
I find your statement to be an assumption rather than a provable fact. All proofs that I'm aware of have to do with temporal relationships within a closed system. If that is so, then your correction of my quote is no more or less supportable than the quote itself. Perhaps, after all, people only live longer now because years are shorter than they used to be.

Bob

 
Actually, we're way off topic here, but there was a recent experiment done with bungie jumpers, where it was shown that people's perception of time passing actually increases when there's external stress. I think it was on the BBC website.

I suppose the reverse might be true too. They just need to perform an experiment at the DMV to show that when you're really bored, you perceive time to slow down. ;-)

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top