My guess: if you look at the number of drive faults you are getting, you
will see that you are thrashing.
In other words, your processor asks for a disk sector and starts reading.
Optimized files will occur with contiguous sectors on the drive (therefore,
as soon as the system is done reading the first sector, the next sector in
line is just coming into range as the head passes over the platter. In the
mean time, thread context switches to another thread, which asks for a
different sector. The first sector is read, but not the all contiguous
sectors. The hard drive seeks to the second location and starts reading
sectors. At this point, the thread context switches, and in your
application, the hard drive goes off again without finishing the optimal
task (it ALWAYS will... hard drive reads are slow, and the processor looks
for something else to do).
This is wildly inefficient. If you have one thread reading a file, it will
read all of the continguous sectors before seeking the hard drive to the
next location. If you have multiple threads reading multiple files, you
will have to seek to the same relative location many times just to complete.
Considering the fact that seeking from sector to sector is the biggest waste
of time in hard drive manipulations, you are NOT better off by
multi-threading an application that hits one hard drive.
This gets worse because you are probably writing to the same drive too,
right?
This phenomenom is called hard drive thrashing, and is similar to OS
thrashing (where so many applications are loaded at the same time that the
OS spends more time performing page faults to switch from one context to
another than it does actually doing any of the work of the applications).
Now, if you were copying files from multiple locations to multiple
destinations, I can see creating multiple threads. But one source to the
same destination is dicey enough without overwhelming it with seeks.
I hope that helps,
--- Nick Malik
Solutions Architect
"John Baro" <jo***@NOSPAMme sware.com.au> wrote in message
news:V1******** **********@news-server.bigpond. net.au...
I have an app that spawns a thread to copy some files.
The spawned thread then spawns threads to copy individual files and wait
for the specific file to finish copying or timeout.
The specific file copy procedure raises an event which gets handled in the
main form from where the original thread was spawned which then updates a
status box and a progress bar.
The first spawned thread raises a startcopy event which the main form
handles to display the progress bar and a finishcopy event to hide the
progress bar.
This was all working peachy until I moved the individual file copying to
individual threads. After that It was REALLY slow and the progress bar
would not display.
When I set the visibility of the progress bar to TRUE to begin with it
works fine. Even after the progress bar has been hidden by the finishcopy event
and shown again by the startcopy event if I run the routine again.
Now for the question.
Why is this so?
I apologize for the long winded explanation but I really dont understand
why this is.
TIA
JB
P.S. The main form "Freezes" when the progress bar is not visible to begin
with. It wont allow me to resize or do anything whilst the filecopying is
going on, even though it is being run in another thread.
