Is this a correct use of wait() ?

[Pho Tek]

Looking at the source of Nokia's sheepdog j2me sample, I noticed this snippet:

    public void run()
 
    {
 
        Thread currentThread = Thread.currentThread();
 

 
        try
 
        {
 
            // This ends when animationThread is set to null, or when
 
            // it is subsequently set to a new thread; either way, the
 
            // current thread should terminate
 
            while (currentThread == animationThread)
 
            {
 
                long startTime = System.currentTimeMillis();
 
                // Don't advance game or draw if canvas is covered by
 
                // a system screen.
 
                if (isShown())
 
                {
 
                    tick();
 
                    draw();
 
                    flushGraphics();
 
                }
 
                long timeTaken = System.currentTimeMillis() - startTime;
 
                if (timeTaken < MILLIS_PER_TICK)
 
                {
 
                    synchronized (this)
 
                    {
 
                        wait(MILLIS_PER_TICK - timeTaken);
 
                    }
 
                }
 
                else
 
                {
 
                    currentThread.yield();
 
                }
 
            }
 
        }
 
        catch (InterruptedException e)
 
        {
 
            // won't be thrown
 
        }
 
    }

On the jchq site, it says:

The wait method is meaningless without the use of notify or notifyAll which allows code that is waiting to be notified that it can wake up and continue executing

In this case, nokia is using wait() as a replacement for Thread.sleep(..). Is this advisable ?

[Val�ry Urbain]

Originally posted by Pho Tek:
Looking at the source of Nokia's sheepdog j2me sample, I noticed this snippet:
[removed]

In this case, nokia is using wait() as a replacement for Thread.sleep(..). Is this advisable ?

NO, definitely NO.
The Nokia sample sucks big time.
ALWAYS use wait() in conjunction with notify()/notifyAll().

[Edward Harned]

sleep() does NOT release the lock (acquired by synchronized.)
wait() does release the lock.

You've only posted a snippet, so we don't know what the code is supposed to do in totality.

Using wait() instead of sleep() may be for the above reason.

[Jim Yingst]

[Edward]: sleep() does NOT release the lock (acquired by synchronized.)
wait() does release the lock.

True. To be fair though, sleep() does not require any lock in the first place, unlike wait(). So in many cases there's no lock to release. Using wait(int) without notify()/notifyAll() instead of sleep(int) makes sense only if you already have a lock for some reason, and you need to release it while sleeping/waiting. This circumstance is fairly rare, but it can happen occasionally. In the above code though, it's pretty clear that the sync lock had not been acquired previously for any reason, and so there appears to be no reason to use wait() instead of sleep() here.
[ November 05, 2007: Message edited by: Jim Yingst ]

[Ugender Rekulampally]

I think you should use sleep instead of wait there.

even using wait() that way is wrong I guess. How are you coming out of the wait? what is the condition that is breaking it out?

if you have to use wait(), then I think you should do some thing like this

while(timeTaken < MILLIS_PER_TICK)
{
 synchronized (this)                     
  {                         
   wait(); 
   timeTaken = System.currentTimeMillis() - startTime;               
  }
}

So this way, there will be a chance for your thread to wait till your desired time is reached.


But using sleep() makes more sense based on the code snippet you provided.


Thanks,
Ugender

[Henry Wong]

Actually, using wait() with a timeout is not very uncommon. It is basically, a sleep() without holding the lock.

However, in this example, the locked is grabbed, only to be released via wait(). Unless, there is code that we are not seeing here -- a sleep() method call would probably be better for this case.

Henry

[Pho Tek]

@Edward & @Henry,

The snippet I gave is a very typical algorithm for a game loop in Java ME.
The usual goal is to ensure we execute one iteration of the game loop in
a fix amount of time i.e. MILLIS_PER_TICK. And if time taken to change the
game state & render the new display is less than MILLIS_PER_TICK; then we
would go to sleep (normally) to run down the time.

So in this case, we all can agree that the use of wait(..) is inappropriate
from a purist viewpoint; but perhaps it is "ok" in for toy java ME apps.

I'm a newbie to java ME world and there's one more thing I find uncomfortable
in MIDP: there is no Thread#isInterrupted().