• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

basic question on releasing a lock

 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Would anyone object to a simple, basic thread question? My question is not motivated by a practical problem. I am only reading about threads.
In Java Thread Programming, Paul Hyde says �When a lock is released, all the threads waiting for it compete for exclusive access. Only one will be successful, and the other threads will go back into a blocked state waiting for the lock to be released again.�
I am wondering about the words �go back�. When a lock is released, do all threads blocked on the lock become runnable? Then one thread is scheduled to run and acquires the lock. Then another thread is scheduled to run, but the lock is taken, so it becomes blocked again.
 
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The concept that you speak of is absolutly correct. However, you can't be so sure of the underlying JVM implementation.
The JVM could do as you say, but in my limited VM experience, I'd think that their implementation would be smarter and just bother to "un-block" one thread.
Eitherway, the method that the JVM uses should not affect the code. Only when you get into advanced performance issues would this matter.
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Dana.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Would anyone object to a simple, basic thread question?
No problem at all. This is a good forum for it.
However I think the answer to this question really depends on how we define various possible thread states. I don't have a copy of Hyde's book, so I don't know how he defines them. The JLS and JVM spec do not define names for thread states (not the ones we're talking about here anyway), so there's really no single official definition. Sun's Java tutorial does have some discussion here. If we use these definitions of "Runnable" and "Not Runnable" (which are unrelated to the Runnable interface) then a thread which is attempting to acquire a lock on a monitor (attempting to enter a sync block) remains "Runnable" the whole time - even if it can't proceed because some other thread is holding the lock. We avoid using the term "wait" for this process because that is used exclusively for what happens when a thread invokes the wait() method - which is a different thing than merely contending for a lock. Note that according to the tutorial definition, wait() does cause a thread to enter the "Not Runnable" state, but contending for a lock does not.
Unfortunately the tutorial does a poor job here of explaining exactly what happens during lock contention. The fact that they didn't bother to present a term for this process is a cause for confusion. And saying that a thread which is trying to acquire a lock is "Runnable" is mesleading at best, since the thread may even be daedlocked at this point. So some authors (Paul Hyde is probably one) have introduced their own additional terms to discuss these subtleties. My old copy of RHE refers to a "seeking lock" state, as well as "ready" and "running" - these are all within the "Runnable" defined by the tutorial. To me, the RHE terms are much more useful - but they're not necessarily standard. Whatever Paul Hyde is using is probably something similar. (Except I see he's used "wait" in a non-wait() context, so I'd be a bit suspicious that his terminology my be misleading.)
Anyway, as Dana correctly observes, the actual implementation behind this stuff is probably smarter than some of the explanations make it sound. It wouldn't surprise me at all if only one thread actually changes state when a lock becomes available. But this is beyond the level of what we can reliably talk about in general - different JVM implementations can do whatever they want here. What matters is that only one thread that syncs on a given monitor will actually be able to run, until the sync block is completed and another thread can have a go at it. Details beyond this are up to JVM implementors.
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Jim.
In my edition of RHE (2002) in Figure 7.7 The monitor states, the transition from the SeekingLock state to the Ready state is labeled lock obtained. Apparently, only the thread that acquires the lock moves to the Ready state.
In Concurrent Programming in Java, Doug Lea�s state diagram has a one-way triangle: runnable -> running -> blocked -> runnable. He does not say if all the threads or only one goes from blocked to runnable when a lock is released.
 
The airline is called "Virgin"? Don't you want a plane to go all the way? This tiny ad will go all the way:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic