[RESOLVED] Question on BackgroundWorker
I am running Visual Studio 2008 on Windows XP.
I have an application that has to process data and insert it to a database, which it does now in the main thread. My computer has multiple processors, though, and I was wondering if I could use BackgroundWorker to utilize both processors.
I'm hoping to use multi-threading to speed up the processing.
So that's the question. If I have two processors and create two background threads, will they both run on one processor or will each run on a different processor?
In other words, will multi-threading help me at all?
Re: Question on BackgroundWorker
Yes, multithreading will help you. The OS will schedule the threads onto whichever processor is free. Even if you only had one processor, using two threads would make the UI more responsive because the OS would swap the threads in and out so that they ran simultaneously. Though each would run slightly slower in that scenario, you wouldn't really notice. Instead, you would just see the UI remain responsive rather than waiting while the other thread finished.
However, multithreading does run simultaneously, and that creates its own challenges. I was looking at pushing a lengthy export process off onto a background thread to leave the UI more responsive, but that would have allowed the user to change the requirements of the export process as it was exporting. So I had to limit what the user could do such that they didn't make the exporting invalid while it was happening.
Multithreading can speed things up, but it can also require careful thought.
Re: Question on BackgroundWorker
Quote:
Originally Posted by
Shaggy Hiker
Yes, multithreading will help you. The OS will schedule the threads onto whichever processor is free. Even if you only had one processor, using two threads would make the UI more responsive because the OS would swap the threads in and out so that they ran simultaneously. Though each would run slightly slower in that scenario, you wouldn't really notice. Instead, you would just see the UI remain responsive rather than waiting while the other thread finished.
However, multithreading does run simultaneously, and that creates its own challenges. I was looking at pushing a lengthy export process off onto a background thread to leave the UI more responsive, but that would have allowed the user to change the requirements of the export process as it was exporting. So I had to limit what the user could do such that they didn't make the exporting invalid while it was happening.
Multithreading can speed things up, but it can also require careful thought.
Couldnt of you just either pass the arguments at the time of 'export'...so even if they changed options...it wouldnt make a difference until the next go around?
or even just set your option boxes as enabled = false?
