> - Scheduler implementation can have m threads
scheduling events for n handlers.
Yes, we all understand that, Harmeet. Peter expressed the basic math for
this issue in the message that you replied to, except that his equation was
labeled with N workers and k scheduler threads, instead of m threads and n
handlers.
> - The watchdog implementation as proposed has one
additional thread per handler. That means number
of available threads for handling protocols can
be at most half of the threads actually used and
allocated by the VM.
ONE of the implementations has an additional thread per handler. The
tradeoff is that there is zero contention and no need for synchronization in
performance critical paths. The OTHER implementation (the shared thread
solution) trades the option to have fewer watchdogs for the overhead of
synchronization and actual thread contention.
> 2 suggestions:
> - Do a comparison of scalability and performance
while varying the thread pool size. You may
notice some patterns.
Nice of you to volunteer "someone." ;-) Who exactly is the ambiguous
person whom you think should be doing this? You aren't capable of running
these tests, yourself, and reporting the results? Right now I'm more
concerned about the behavior that I am seeing in common.
> - Create a watchdog implementation that has m watchdog
threads watching n handlers and you may notice the
same multithreading issues in it that you are refering to.
Harmeet, don't you get it? That is precisely what you have already done.
Your code IS that implementation. The watchdog depending upon context and
capitalization, is only a concept or an interface. An implementation of M
threads watch N handlers is what your code provides. So OF COURSE we would
see the same issues.
> Peter: Are you saying we should always have this strategy
> One additional thread per handler to watch for timeout?
Yes, that's what is being said.
> If not, please send an implementation that allows m
> watchdog to n handler mapping?
See above.
> 1 watchdog thread per handler is too heavy for timeout.
> Timeout to some extent can also be handled by Socket
> timeout settings.
soTimeout doesn't address either the memory issue I am seeing right now, or
the basic issue of a watchdog, which is to check for other problems that
might hang the thread. I do agree that soTimeout should be used.
As for 1 thread being too heavy, might I point out the performance numbers
that I have already reported? For the same message load, the shared thread
implementation is running between 50% and 100% higher CPU utilization. And
since that result occurs with A SINGLE CONNECTION, the number of threads is
the same for each implementation. Therefore, considering that most of the
code is in common, I'd venture to say that almost all of that excess is
located in the code that is different, e.g., the shared scheduler thread.
In other words, there *appears* to be a 50% to 100% perfomance penalty, even
without contention.
> If you have an m watchdogs to n handlers implementation ...
You just really don't get it, do you? That is what you have implemented.
And, yes, we see the contention issues that Peter raised.
> One way of reducing contention is to not have shared datastructure.
> You may notice that the implementation does that. Datastructures
> per thread are mutually exclusive and don't have contention.
That is why the dual thread model is more efficient.
> Scheduler contention characteristics can be changed by having
> different values for thread count and idle time parameters.
That can CHANGE the contention characteristics, but not eliminate them. The
fact that a block CAN be contended means that you MUST synchronize it.
Synchronization imposes a significant performance penalty regardless of
whether or not any contention is actually occuring. See above for the
impact that it appears to be causeing.
> BTW. I am not saying and have never said scheduler is the right interface.
Fine.
> Agreed there can be other implementations, but I have seen only
> one so far.
What part of the proposal to use your code AS THE SHARED THREAD WATCHDOG
IMPLEMENTATION don't you understand? You keep saying the same thing --
talking about an N thread for M worker Watchdog -- completely missing the
fact that I proposed exactly that thing.
Hello? Harmeet? I feel like I'm doing a vaudeville routine with you.
<<knock, knock -- is this thing on? Can you hear me? Someone turn on this
microphone>> The proposal is that BOTH the dual-thread and shared thread
implementations would be available under the same interface. Do you
understand?
Repeat after me: both implementations will be available. Can you say it?
C'mon, you can say it: BOTH implementations will be available. :-)
> a good abstraction for such a watchdog or timeout event scheduler
> Talking about release, I had requested someone post a schedule or
> thoughts on it.
Gee, I'd like to fix this memory consumption problem. How about you?
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
