On Sat, 18 May 2002 03:21, Steve Short wrote:
> In cornerstone/blocks/scheduler/DefaultTimeScheduler class the addTrigger()
> & rescheduleEntry() methods notify the waiting thread only if the first
> entry in the priorityqueue matches the current entry.
> if( entry == m_priorityQueue.peek() )
> {
> notifyAll();
> }
> As a result of this, the waiting thread (the run() method)
> synchronized( this ) {
> wait( duration );
> }
> does not get notified & does not get a chance to remove invalid entries
> from the queue (old entries invalidated by rescheduleEntry() method) & the
> queue keeps growing until the wait times out, the timeout value depending
> on the value specified to the trigger.
>
> My question here is why don't these methods send a notify after it finds
> any entry in the queue, so that the waiting thread gets a chance to clean
> up all invalid entries? Or is there some other thread notifying this
> thread?
The idea was that you only needed to wakeup the monitor thread if the entry at
the top of the heap changes. The reason being that the top entry on heap is
always the next entry to run. Invalid entrys are only removed when they get
to the top of the heap and we goto look at them. So even if we woke up the
monitor thread it would not be able to delete invalid entrys unless the top
entry happened to be invalidated.
What this means is that there can possibly be lots of invalid entrys inside
the heap if you schedule them far enough into future and keep rescheduling
them. At one stage we were going to have a "reaper" thread that went through
and removed all the invalidated entrys but it never got done as the worst
case scenario (schedule in future then reschedule) is rare enough not to be
an issue.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
