Topic
2 replies Latest Post - ‏2007-10-09T14:43:54Z by SystemAdmin
SystemAdmin
SystemAdmin
1240 Posts
ACCEPTED ANSWER

Pinned topic Thread.sleep(..) and the lock reacquisition algorithm

‏2007-10-06T19:55:57Z |
Hi,

Given: Thread.sleep(..) unlocks all locks of the current thread

Let's say that the current thread (let's call it T1) holds 5 locks.
Then Thread.sleep(10000) is called from T1.
All 5 locks are released.

In order for T1 to resume execution, it must acquire all 5 locks again (sometime after the 10 sec timeout). But is it specified how T1 would go about doing this? For example:

(1) Does T1 place itself in the entry set of all 5 monitors?
(2) Does T1 insist on an all-or-nothing acquisition of the 5 locks? That is, must there exist a time at which all 5 monitors are available and then T1 grabs them all atomically in one go? This is the scenario that prompted this post. If this is the case, then it's likely that T1 will take a long time (if ever) to resume execution if there is no window of opportunity during which all 5 monitors happen to be available.
(3) Or, what makes more sense to me, is: Does T1 re-acquire its 5 locks gradually -- rather than case (2), does T1 re-acquire each lock as it becomes available, and then, when the last of the 5 locks is acquired, T1 resumes execution?

If you're pulling your car out of a supermarket and you need to turn left onto the street (where people drive on the right side of the road) where there is no stoplight, then you have at least 2 options:
1) Wait until there are no cars going in both directions, and then step on the gas and make your left turn.
2) Wait until there are no cars going to the right. Then go to the middle lane between the 2 lanes of traffic (whatever that yellow lane is called), and then wait until no cars are moving to the left, and then go left.

So with 5 locks, I think of the game Frogger where it's a lot easier for your frog to cross a 5-lane road if you go 1 lane at a time rather than wait forever until all 5 lanes are clear... the latter opportunity may never come.

Thanks,
Will
Updated on 2007-10-09T14:43:54Z at 2007-10-09T14:43:54Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    1240 Posts
    ACCEPTED ANSWER

    Re: Thread.sleep(..) and the lock reacquisition algorithm

    ‏2007-10-06T23:24:04Z  in response to SystemAdmin
    Well, it turns-out that my "Given" was wrong... oops.

    Thread.sleep(..) holds all its monitors while sleeping, so in that case I no longer have an issue with this. There can't be a lock re-acquisition algorithm if Thread.sleep(..) never gives-up its thread's locks in the first place! :-)

    Although, I'd be interested to know if there is any call that would cause multiple locks (from different monitors) to be temporarily unlocked at the same time. I wouldn't think so.

    I know that Object.wait() unlocks/releases the monitor that was most recently entered by the thread that executed the wait() call (no matter how many times that monitor was re-entered/re-locked by the same thread -- ie, no matter what the lock count of the monitor), but all the other monitors of the thread are still held during the wait().

    Thanks,
    Will
    • SystemAdmin
      SystemAdmin
      1240 Posts
      ACCEPTED ANSWER

      Re: Thread.sleep(..) and the lock reacquisition algorithm

      ‏2007-10-09T14:43:54Z  in response to SystemAdmin
      > Although, I'd be interested to know if there is any call that would cause multiple locks (from different monitors) to be temporarily unlocked at the same time.

      This would be a Very Bad Thing and would render the call useless in practice. There is no way for a called function to know which order the locks should be reacquired in to prevent deadlock.