Printable View
hey guys,
I have a application which processes 1000's datas.. for each processing it needs to update gui and db and many variables in my application. So what i have planned is to use 50~90 background worker with my own algorithm of thread pool, synchronization and thread close...
So here is it efficient in terms of memory and performance.... just confused what to use.. backgroundworker componenet or standard thread..
All of these methods use threads. The difference is only a matter of delivery. i.e. The threads used by BackGroundWorkers and threads created using Thread objects are the same.
However, threads themselves can either be background threads or foreground threads, the difference being that program terminates when all foreground threads terminate and background threads always terminate when all foreground threads are terminated. The BackGroundWorker component uses background threads by default I believe while Thread objects create foreground threads by default. However, Thread objects can be made to create background threads by setting its IsBackground property to True.
Neither. You should use the ThreadPool directly. A BackgroundWorker does its work on a ThreadPool thread anyway, so even if you did create that many, they still wouldn't all execute at the same time if the ThreadPool didn't support that many threads. What you should do is loop through your thousands of data items and call ThreadPool.QueueUserWorkItem for each one. The ThreadPool will then manage the number of simultaneous operations and thereby prevent you from bringing the system to a grinding halt.
The BackgroundWorker makes it easy to update the UI from a background thread by allowing you to simply call methods and handle events, which is familiar to all. That doesn't mean that it's necessarily all that hard to update the UI without a BackgroundWorker. You just have to come to terms with a new concept. Updating the UI from a method that is executed on a background thread is the same whether you use the ThreadPool or create a Thread explicitly yourself.
Can a List(Of Thread) be made to do the same thing ? Whats special about the ThreadPool ? I've never used that before for threading but I've seen it mentioned multiple times around here. I guess what I'm really asking is if ThreadPool threads have some special quality or properties that set them apart.Quote:
Originally Posted by jmcilhinney
ya i understand... so suggesting me to use threadpool and to queue works.. thats fine.. i had that idea but i though to create around 30~90 threads and use synchronize function to assign work at a time and there itself have a code that closes thread if no work is there... so what about this idea?
The threads themselves are no different but it's the ThreadPool itself that adds the extra functionality. The ThreadPool manages the number of threads for you. It has a minimum number of threads that it keeps alive all the time. It will create additional threads up to a maximum as required and then let them terminate when they are no longer needed. You can queue up as many tasks as you like and the ThreadPool will manage how many get executed simultaneously, automatically picking the next task off the queue when one completes.Quote:
Originally Posted by Niya
It's worth noting that just about any task that you perform in .NET that involves any sort of parallelism other than explicitly creating your own Thread and calling its Start method will use the ThreadPool implicitly. Any time you call an asynchronous method, i.e. any method whose name starts with "Begin" or ends with "Async", the work will be done on a ThreadPool thread. Note that to use a BackgroundWorker you call its RunWorkerAsync method, so the DoWork event handler is one example of a method that is executed on a ThreadPool thread.
I can't see how that offers any advantage over using the ThreadPool and it will require more code to manage so I would recommend against it.Quote:
Originally Posted by yogesh12
Thanks.... Actually i thought, if we use threadpool, we need to do more hard coding to synchronize, and less efficient (in terms of performance..)Quote:
Originally Posted by jmcilhinney
Using the threadpool would result in less synchronisation code. What you're suggesting in your first thread could be paraphrased as "reimplement the ThreadPool". If you try that, you'll find yourself with a buggy ThreadPool with poorer performance. The ThreadPool provided by .NET has had a lot of smart people who know a lot about threading and Windows looking at it for a long time. There is no way an individual programmer could create something anywhere close as good.
You're far too modest EG. ;)Quote:
Originally Posted by Evil_Giraffe
guys here i am discouraged and encouraged! i will use thread pool, monitor time take to complete task and memory, and i will implement my own algorithm and monitor with that too... i will post results here later today when i am back home..
Thanks guys!
Hahahaha.Quote:
Originally Posted by jmcilhinney
I used to phrase my advice in such a way that most people interpreted it as "You couldn't build as good as this library, but, hey, I probably could. Because I'm 99% AWESOME (and 1% SUPER AWESOME)"
I've tried modifying it to more clearly state that I include myself in the "couldn't build it as well" group.