David ,
I actually agree with Thomas - I would use a threadpool. If a library
requires a single threadid use a higher priotity schedule thread to pass the
work information to the threadpool. Threads are not a performance issue
like going to the DB but they do consume resources and large numbers do
cause the OS to become less efficient.
If it does not work then I would change to the large thread model but I
would think 5-20 ms to start a Thread would not affect voice type
performance. If the switching work is small , high quantity and time
critical ( < 10 ms) then you would probably be better of staying in an
unmanaged environment. JIT compiling can be a killer for real time work.
You should also note ThreadPool has a limit of 25 threads per processor.
With managed threads something funny goes on .(see my earlier posts) .
Ben
-----Original Message-----
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED]]On Behalf Of David Williams
Sent: Monday, 1 July 2002 9:54 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Massive Use of Threads Issue
Andy, you are correct in that the software library that I have available to
me does have a thread affinity issue. I can not handle multiple resources
per thread at all (I have to pass the actual threadid to the library so
that it knows how to talk to the application - the only indicator of which
resource is talking to me is the returned threadid.) Everything is event
driven, so I do not have control over when something happens (very similar
to working with a form). "Responsiveness" is the key indeed. I can NOT
put someone on "hold" while I process someone else. Every caller must
think that they are the only one on the system (save in a conference call).
While there is some database activity for inbound calling (i.e. finding who
is calling me), I have designed the system to reduce the amount of external
resource activity to a minimum. I have found the hard way, over the last
four years as a telephony programmer, that trying to do any kind of
external work DURING a call is a big NO-NO. I do it all before or after
the call. During the call the only external work I do is to find the
scripts needed and to cache the prompt files.
David Williams
|---------+------------------------------------->
| | "Mcmullan, Andy (Andrew)" |
| | <[EMAIL PROTECTED]> |
| | Sent by: "Moderated |
| | discussion of advanced |
| | .NET topics." |
| | <[EMAIL PROTECTED]|
| | EVELOP.COM> |
| | |
| | |
| | 07/01/2002 07:45 AM |
| | Please respond to |
| | "Moderated discussion of |
| | advanced .NET topics." |
| | |
|---------+------------------------------------->
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: [ADVANCED-DOTNET] Massive Use of Threads Issue
|
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
Thomas, I'm surprised that you can provide such an apparently definitive
answer without knowing more about the environment.
For a start, the hardware vendor is likely supplying software libraries
used to interface with the boards. It may be that the design of these
libraries makes a thread-pool approach difficult. For example, telephony
applications generally wait on events from the board (e.g. events
signalling incoming telephone calls) - how are these events exposed? Async
calls from library-created threads? Or does the application thread need to
call a blocking library call to wait? Is thread affinity an issue?
Although developers are generally educated that "many threads is bad", it's
not necessarily true in all cases. With telephony resources you have
distinct 'ports' (or 'timeslots') that logically fit with threading in such
a way that one-thread-per-resource can make a lot of sense. Node that peak
throughput is not usually the main requirement in a telephony system.
*Responsiveness* is the key. No point having 30 callers being handled
super-efficiently if that means 200 other callers are being kept 'on-hold'.
Better to waste a bit of CPU context-switching and handle all 230 callers
simultaneously.
So my advice to David would be to not get hung up on the number of threads.
300 threads is not by itself going to cause you any fundamental technical
problems. My first thought on reading the message was "Are you really going
to be able to handle 288 concurrent telephone calls on one PC?". Maybe you
should think about spreading that load across multiple PCs, both for
performance and for redundancy in the face of a hardware or software
failure. But obviously a lot depends on what exactly the application is,
how much non-telephony processing (e.g. database access) is required during
each call, etc etc.
Andy Mc
-----Original Message-----
From: Thomas Tomiczek [mailto:[EMAIL PROTECTED]]
Sent: 01 July 2002 10:56
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)
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.
