• Post Reply Bookmark Topic Watch Topic
  • New Topic

Is this a correct use of wait() ?  RSS feed

 
Pho Tek
Ranch Hand
Posts: 782
Chrome Python Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looking at the source of Nokia's sheepdog j2me sample, I noticed this snippet:

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
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 291
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[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
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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



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
author
Sheriff
Posts: 22861
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 782
Chrome Python Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@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().
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!