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

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.

Tom

_________________________________________________________________
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess



-------------------------------------------------------
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