You should all head over to RBLibrary.com and "purchase" my latest article. Remember how I asked everyone for their thoughts on thread pools? Well, that little side project turned into a full-fledged article. To make things even better -- it's totally free. 100% no-cost-to-you-so-what-are-you-waiting-for? So if you haven't already grabbed a copy of it yet, I suggest you get over there and snag it; I think it's a very interesting project and a good read.
For those of you who have gotten it, feel free to leave your comments/questions here.
Indeed a perfect article with included a working exampleprogram. Very pleasant to read and with that example things are much better understandable.
This way it's a real hands-on-experience.
Very fine job done! Congratulations!
Uh, you chowderhead, didn't I tell you the only way to pay the server bills, bandwidth bills, labor bills, electricity bills and food bills are by charging, even a pittance?
Ahhh, impetuous youth.
You know me Bill, always happy to give it away. That's what you get for leaving me to hold down the fort for two weeks. :-P
Thanks for writing this article and making it free. BTW, I'm busy writing the article I promised for you. I think that the big bad migraine is finally over.
My pleasure, and thanks! :-)
@ Aaron - Thank.
@ Bill - I just bought four other paid articles because of this clever little bait... ;-)
@ Gerard - Cut up credit card...
@Gerard -- glad to hear my evil plan worked. ;-)
Thanks for the great article and example... and your evil plan also worked with me...
A question about your article and using he same example. If I didn't want to hit the download server with all available sockets at same time, but say with only two 2 sockets each time and have a delay about 2 seconds between jobs, what would be the best approach to this? Would be to use only two threads and do a sleep... where? In the ThreadPoolThread or ThreadPoolManager?
Neither -- the work item, if you must. Personally, I would modify the way I queue the items up (put the delay up front). But you can also put the delay in the work item's InitializeItem method. The work item can decide "hey, I need to sleep for a while" by checking some flag. But I would not modify the thread pool manager or the thread pool thread itself; that's the wrong level for changes like that.
@Aaron: Thanks!
Aaaron, thanks for this article.
I have modified the ThreadPoolManager a bit : instead of running every N ticks (me.Sleep( 1000, true ), I suspend it. It is then resumed by either :
- queueing a new action
- getting notified of the end of a thread run event
The idea was not to run at all unless there's a good chance that ThreadPoolManager has something useful to do.
Is there any risk associated with this idea ? Should it be overall slower or faster ?
Best regards
That idea certainly works; I don't see any issues with doing it that way.