• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

if wait() can't immediately reacquire the lock, then...?

 
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

how do we ever make it to checkpoint d? right after checkpoint b
we tell the other thread waiting on the Object (by calling
obj.notify() ) that it's wait() should try to reacquire the lock
on the Object so it may continue. *But* since we drag our feet
with the sleep(), during that time, shouldn't the other thread's
wait() see that it cannot get the lock at this time, and just go
back to wait()'ing?
 
John M. Gabriele
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
whoops! i understand it now.
calling notify() on an object upon which other threads are
wait()'ing simply switches the waiting thread's "state" from,
waiting regardless of whether or not the object has a lock on it
to
waiting to grab the object's lock as soon as it is available.
i hope this post helped others. it helped me. heh.
 
Don't get me started about those stupid light bulbs.
    Bookmark Topic Watch Topic
  • New Topic