I'd just add that there are options to consider when using a thread pool. You can manage one yourself or use the built-in thread pool. When using the builtin thread pool you have much less to do/worry about including the thread count - since its all managed for you. When you roll your own you have much more control - "but with control comes responsibility". I'd start with the builtin threadpool and test how that suits you.
There's a chance that depending on your load profile the builtin thread pool may not perform that well. Particularly if you have significant spikes. This is due to the way threads are added/removed from the pool. Jim > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]]On Behalf Of > Thomas Tomiczek > Sent: Monday, July 01, 2002 5:56 AM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Massive Use of Threads Issue > > > You are dead :-) Frankly, tell your hardware vendor to stick > to hardware > and not to advice people with unusable software designs. > > Use around 20-30 threads per processor. Take requests and > dispatch them > to a thread pool. Use a "work ticket" based design, taking a > work item, > have a thread handle them. Use pooled database connections. > > Regards > > Thomas Tomiczek > THONA Consulting Ltd. > (Microsoft MVP C#/.NET) > > -----Original Message----- > From: David Williams [mailto:[EMAIL PROTECTED]] > Sent: Sonntag, 30. Juni 2002 22:37 > To: [EMAIL PROTECTED] > Subject: [ADVANCED-DOTNET] Massive Use of Threads Issue > > It the component design that I have, it appears that I am going to end > up > with something on the order of 300 threads running. My question is > simple. > Is this number of threads going to cause me massive headaches? > > Okay, before you ask, the reason that I have this design is > that I have > a > number of large telephony boards (3 QuadSpan T1's) where I am > being told > by > the hardware vender that I should be handling each channel - > that is all > 288 of them (24 channels to a T1, 4 T1s to a card, 3 cards = 288) on > separate threads. This is so that there can be little to no delay on > one > channel regardless of what is happening on any other channel. Makes > sense > to me, but then I have to worry about things like that fact that I do > not > want to have 288 connections to the database, so I have to create yet > another thread to handle the database - and I still have not > figured out > to > handle async calls to a database (SQL Server) in ADO.NET. Plus I need > to > log all actions to a separate database - yet another thread. Plus > comminations to one or more GUI applications that control and monitor > this > monster. At least two more threads - one to handle the > remoting and on > the > handle the GUI (if on the same box - which it will be at first). > > So, what I am asking is what is the best method to keep this kind of a > message from giving me a massive headache? I have been trying to come > up > with a simple design for this all, but keep stumbling around (it does > not > help that I am not all that conferrable with threading in the first > place. > I am after all a VB6 programmer moving into the VB.NET world. And how > did > I handle this in VB6? Separate programs that is how. (Tallk about a > nightmare!)) > > So, any suggestions on the best approach for something like this would > be > great. > > David Williams > > You can read messages from the Advanced DOTNET archive, > unsubscribe from > Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > You can read messages from the Advanced DOTNET archive, > unsubscribe from Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
