Re: FYI: FiniteQueue blocking dequeue (all 3 methods) don't respect timeout

Yes, you missed something.
1-The code I gave is the body of the loop.
2-This is a dequeue method. We expect to get a notify (from enqueue) before the timeout.
(This timeout is currently the blocktime in the TPSTM config.)

here is the one of the blocking_dequeue method, full src.
it could be trimmed a bit of useless IFs and conditionnal currentTimeMillis().
it supports interruption (unlike pretty much everything else in the original seda, I had to
refactor a lot everywhere...).

public QueueElementIF blocking_dequeue(int timeout_millis) throws InterruptedException {
	QueueElementIF rets = null;
	long goal_time;
	
	goal_time = System.currentTimeMillis() + timeout_millis;
	synchronized (blocker) {
		rets = this.dequeue();
		if ((rets != null) || (timeout_millis == 0)) {
			return rets;
		}
		
		while (true) {
			if (timeout_millis == -1)
				blocker.wait();
			else {
				long delay = goal_time - System.currentTimeMillis();
				if(delay>0)
					blocker.wait(delay);//timeout_millis);
			}
			
			rets = this.dequeue();
			if (rets != null) {
				return rets;
			}
			
			if (timeout_millis != -1) {
				if (System.currentTimeMillis() >= goal_time)
					return null;
			}
		}
	}
}



--- tom strickland <[email protected]> wrote:
> My first post to the list... hullo everybody!
> Comments below...
> 
> At 2003-10-16 15:44,  Quartz <quartz12h@ya...> wrote:
> >FiniteQueue timed out blocking dequeue (all 3 methods) does not
> >respect prescribed timeout:
> >  (oh, that's a shocker...damn FiniteQueue)
> >   In all blocking calls (timed out), the the timeout does not decrease.
> >  //if (timeout_millis == -1)
> >//    blocker.wait();
> >//else
> >//    blocker.wait(timeout_millis);
> >  Should be like this:
> >  if (timeout_millis == -1)
> >     blocker.wait();
> >else
> >{
> >     long delay = goal_time -System.currentTimeMillis();
> >     if(delay>0)
> >         blocker.wait(delay);
> >}
> 
> Yes - except of course, this does not cope with spurious wakeups. According 
> to the JLS, a thread can be woken from a wait(n) or sleep(n) state before 
> time n has elapsed. As far as the programmer is concerned, the reason for 
> this wakeup is not relevant - hence 'spurious wakeup'. Better to wait like 
> this:
> 
> [...]
> else
> {
>     while( goal_time < System.currentTimeMillis())
>     {
>         blocker.wait(goal_time - System.currentTimeMillis();
>     }
> }
> 
> 
> The same point probably applies to the "blocker.wait()" bit.
> 
> Unless I've missed something.
> 

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl