> So propose an alternate interface.
I did. And one that supports BOTH implementations.
> Propose and implementation and measure the benefit.
> Why is that problematic with this approach ?
I believe in proper design. As the IBM paper mentions, proper DESIGN is the
most important issue with multi-threading. It is hard and time consuming to
load test a multithreaded implementation, and even though I am willing to
spend some time doing so, I really have my own work to do.
You tried using Timer, and I had to explain why that fails. You refered to
Doug Lea, and I pointed out that his code uses two threads per timed
operation. In fact, if you look at the CommandMap implementation that I
posted months ago, you will find very similar code for handling time guarded
operations. I hadn't looked at Doug's code until tonight, but although it
is gratifying to see the similarities, it isn't surprising. There are
certain known techniques, and this one is a classic within our field.
> Believe it or not, I have a fix mitigate synchronization issue.
> It is really simple and implicit in your messsage. :-)
I look forward to seeing, it. HOWEVER ...
You have said that you wonder why Avalon and Sun have such inefficient
implementations. They are not inefficient. They are designed for a
particular task. There are certain assumptions about how schedulers are
used. They implemented the code so that they could minimize the contention
issues for multiple users, thus allowing their classes to be more scalable.
The tradeoff there is that they simply mark removed items as reset, and
clean up later. In normal operation (for a scheduler), both of those
implementations use far less memory and far less CPU than your class. As I
have said multiple times, there is a difference between a Scheduler and a
Watchdog.
Earlier you indicated that you would accept being wrong. Now you are
holding onto an idea for which no one else has expressed support. I admire
sticking to your beliefs when everyone else says that you're wrong, and I've
been willing to help you investigate a shared thread solution, but at this
point I do not see that this is contributing to improving James. It is just
making everyone frustrated, and I, for one, am not happy with the idea of
maintaining the status quo because one person won't allow the project to
move forward.
I have suggested a compromise. Peter says that he'll do the work to
implement the compromise. Both implementations will be in the code. The
work is already done. What is your issue with accepting this solution?
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
