 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / March 2007Asynchronous delegate vs thread pool & thread
This is quite an issue for me when doing debugging for async delegate call (i.e., using BeginInvoke). Note this is NOT Control.BeginInvoke, which runs on the thread creates the control. According to MSDN: If the BeginInvoke method is called, the common language runtime (CLR) will queue the request and return immediately to the caller. The target method will be called on a thread from the thread pool. SO it comes to Q1: is this thread pool the same one as System.Threading.ThreadPool? What if I have used System.Threading.ThreadPool to its full capacity and there is no more free thread available there? Will the BeginInvoke be blocked there? If so, the design of async delegate has problem. Also, since thread and thread pool is already there in the framework, what is the necessity of the existence of asycn delegate then? Or what is the difference between them? Thanks in advance. I have been puzzled by above questions for quite some time. > This is quite an issue for me when doing debugging for async delegate call > (i.e., using BeginInvoke). [quoted text clipped - 6 lines] > SO it comes to Q1: is this thread pool the same one as > System.Threading.ThreadPool? Yes. > What if I have used System.Threading.ThreadPool > to its full capacity and there is no more free thread available there? Will > the BeginInvoke be blocked there? If so, the design of async delegate has > problem. Well, it will wait until a thread becomes available. The thread pool is designed to run short-lived tasks. Personally I think it's a pity that there's just one thread-pool, rather than allowing users to create their own instances which they can control themselves (e.g. by only using one thread-pool for a certain type of task, leaving the system thread-pool free). > Also, since thread and thread pool is already there in the framework, what > is the necessity of the existence of asycn delegate then? Or what is the > difference between them? There are often multiple ways of accomplishing the same thing. It's often easier to call BeginInvoke, passing in the appropriate parameters, than to call QueueUserWorkItem. Other times, QueueUserWorkItem is simpler, if you need a callback but don't need to pass in more than one piece of state.  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too > If the BeginInvoke method is called, the common language runtime (CLR) > will > queue the request and return immediately to the caller. The target method > will be called on a thread from the thread pool. > SO it comes to Q1: is this thread pool the same one as > System.Threading.ThreadPool? I see Jon already answered, but I'll second his answer: Yes, it's the same thread pool. > What if I have used System.Threading.ThreadPool > to its full capacity and there is no more free thread available there You're screwed. To help with this a little bit, the next service pack to .NET will increase the default size of the thread pool. This won't solve the problem, but it'll make things a bit better. http://www.bluebytesoftware.com/blog/PermaLink,guid,ca22a5a8-a3c9-4ee8-9b41-667d bd7d2108.aspx > Thanks in advance. I have been puzzled by above questions > for quite some time. For Server applications, I recommend against using the thread pool. It leads to too many issues. The problem becomes especially acute if you're doing I/O bound synchronous processing on thread pool threads - for example, a database call. In these cases, your server will completly deadlock, and you're stuck restarting the process. I've blogged about this, and the related issues, here: http://www.coversant.com/dotnetnuke/Default.aspx?tabid=88&EntryID=8 Joe Duffy (at the time, he was in charge of Concurrency for .Net at Microsoft) has also written some great pieces on this problem: http://www.bluebytesoftware.com/blog/PermaLink,guid,fe3434c7-b3b7-42c8-9267-df99 6c9c222a.aspx http://www.bluebytesoftware.com/blog/PermaLink,guid,ed78e4f1-fcaa-47a8-920b-804f e217c9d3.aspx SignatureChris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP http://www.coversant.com/blogs/cmullins Thanks very much, Jon and Chris. Chris I am going to read those links and thanks again for that. Actually we are building a server part of whose service is to transfer files to clients. Since thread pool provided ways to set its maximum thread, we just use it to control the server load. But after reading your explanations, I just found what we doen is a potential time bomb. Suppose there are many files in the threadpool queue already, and if we have any asynchronous delegate calls (Or something else using the thread pool) requires a fast response, then the things will really get screwed up. Jon you are right that it is a pity to have only one threadpool. I also feel this is something like a defect by design. If threadpool is open for user to use, then async delegate shall not use it in a hidden way which many of the developers cannot see. I wonder if there is any other stuff also sharing the threadpool? Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.