Printable View
From what I've heard your program get faster if you make it multithreaded. Is this really true? I mean, if your program does some heavy calculations it's still going to use most of the processor's power anyway. So multiple threads wouldn't give it more processor time. Am i wrong?
It's still nice if you want several things done simultaneously in an easy way though, like a 20 minute calulation without the window interface locking up :cool:.
If the task is singular, like running a calculation, then I doubt it.....the thread syncronisation you would need to run both threads on a single task would probably slow things down....
true and false. On a multiprocessor machine multithreading MAY make your code faster. On a uniprocessor machine multithreading WILL make your code slower. What multithreading does give you tho is the ability to be doing calculations or whatever and still keep your apps message pump running without having to resort to the old win3 style of unresponsive window and hourglass cursor whenever anything calculation intensive was going on.
You can make your program slower by multithreading. Multithreading is suitable for some tasks, not for others. People often refuse to believe this, so on my old software site, I had a program which ran three routines one after the other then ran them in three concurrent threads, the timings showed the multithreaded version was slower.
Unfortunately, that tutorial is not up on my new site yet, so you can take my word for it or not. Simplistically, it works like this, if you are the only task running, then all of the CPU is available for you in user mode. If you have 2, (or more), threads running, some of the CPU time is going into kernel mode to perform the context switches between the threads...
>>> like a 20 minute calulation without the window interface locking up
... that, on the other hand, is a perfect use for threading, one I use almost routinely.
*** EDIT ***
Ooops, little multithreading there SC!
Ok, thanks for clearing that out!
Its said to avoid multithreading in the place of a single thread
app whenever possible in order to avoid slow down & unwanted
bugs,& overhead.
thread coordination(synchronization)between different threads
(interupt by OS of a thread at the wrong time)in some graphical programs could be a diff task to master.
I have Q though.
in multi threading every thread has its own msg queue.
how can this be of any use if for instance one thread actually
needs some data from another one to begin execution.
in effect calling the prog multithreaded is cosmetic, isn,t it?
>>> for instance one thread actually
needs some data from another one to begin execution.
I don't think I understand your point.
One of my recent projects had the main thread running the UI, a worker thread scanning a series of directories looking for files arriving on the machine via a wireless lan from buses driving past.
Every time a new file arrived, the scanner thread spun another thread passing it the path to the file, so in that respect, yes, the new thread needed input from another thread to start. After it had started, the new threads open, read, validate the files, update a statistics database, make secure copies of the files on other drives, and finally upload the data into an Oracle database. Once started, the threads are completely independent of the initiating thread, or any other file processing thread, (they send status to the UI thread with PostMessage()). Since there is a huge amount of blocking I/O in the file processing threads, the threaded version of this system runs hugely more efficiently then a single threaded program could ever hope too, and retains a snappy UI.
In what way is that cosmetic?
>>the threaded version of this system runs hugely more efficiently then a single threaded program could ever hope too, and retains a snappy UI.
what i meant was in the case of smaller programs.
In your case yes;due to efficient coding
but in some other programs, its risky to let the child threads
to share the same file(knightMove)in a chess game
at the same time(reading&writing&deleting).
so the solution is(atleast what i think it to be).not to release
the control from one child thread untill its done with KnightMove file. so indvertantly it wont corrupt original data.
in your case you probably forsaw that by creating copies of the
original files in other drives. some programmers may not go that far.