All,
> But you cannot eliminate them. That is simply the nature of the
beast. I
> haven't counted the bytecodes for the operations, but I believe that
even
> if
> there were no synchronization overhead issues, there would still be no
way
> to be within 1000 times the overhead of resetting the timer in the
> dual-thread implementation. It simply takes a lot more time to manage
the
> shared data structures. And, of course, there are still those
> synchronization and the delays it causes on ALL OTHER waiting threads.
Noel is entirely correct here.
> > (b) There are ways of improving it more. Doug Lea has documented a
few
> ways
> > and has a library to help eleviate problems you are mentioning.
>
> I am familiar with his work, and I don't believe that you are correct.
> His
> e-mail address is [EMAIL PROTECTED] Would it help if we pull a Woody
> Allen,
> and ask Doug Lea to stop by? ;-)How's about if I point out that Doug
> Lea's
> own watchdog code uses two threads per operation? Please read his
> implementation, not just his interfaces.
Indeed. As Noel pointed out to me, the most similar class can be found
at
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/Tim
edCallable.java
The major difference in purpose from the Watchdog idea is that the
TimedCallable is not intended to be reset. So Watchdog is a little more
complex. But note the similarities - multiple threads (2) in each
implementation, no centralized map to cause contention. Doug Lea is one
of the world's experts on Java threading. Personally, I trust that he
knows what he's talking about.
> > If we had release with your patch and Danny had not tested,
> > there would have been a significant regression and no easy
> > implementation swap.
This is actually incorrect. Danny's issues were due to
misconfiguration, not code errors. There was one errant notify(), but
it did not cause the problem Danny observed.
As I noted in my original patch submission, testing was still underway.
I caught the errant notify() in the load test, and corrected it. Piece
of cake. And that's exactly why one does testing.
> We aren't supposed to put out code without testing. And YOUR code was
> even
> worse than his until I tested it, and you improved it. Code is rarely
> perfect as first written. Not even mine.*
Of course.
> > Let us talk code and results rather than take up mutually exclusive
> > positions.
>
> I have been. I have proposed a compromise that allows the choice of
> either
> implementation. Peter is willing to do it. The code is already
written
> to
> allow this compromise. Please accept it.
I'm fine with the compromise. I've already written a factory class to
provide this functionality and altered the handlers as necessary. I
can't imagine why anyone would use the centralized Scheduler, but
whatever. As long as I can run a proper timeout mechanism off the code
base, I'm happy.
--Peter
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
