Object and Thread class

[Kumaran Pillai]

Can someone explain me in detail why the methods "wait(), notify() and notifyall()' are declared in Object class rather than Thread class.

Thanks in advance for your help.

[Henry Wong]

Originally posted by Kumaran Pillai:
Can someone explain me in detail why the methods "wait(), notify() and notifyall()' are declared in Object class rather than Thread class.

Thanks in advance for your help.

Well, first of all, wait() and notify() should not be related (1:1 coorespondence) to the Thread class. Think about it. You wait on a condition -- which is related to data. One thread can wait, or a dozen threads can wait. There can be one condition to wait for, or there can be a dozen different condition to wait for.

On the other hand, it shouldn't be related to the Object class either. The reason wait() and notify() is with the Object class, is because it is related to synchronization. And since each object can be used for synchronization, they allowed each object to be used as a condition variable.

Unfortunately, this isn't correct either -- as it is possible to have more than one condition related to a synchronization lock. Anyway, this has been fixed with Java 5, but you have to use the newly created Lock class, and its related Condition class -- instead of the synchronization keyword and the wait() and notify() methods.

Henry

[Pho Tek]

Henry,

Can I say that using the new concurrent.locks primitives, one will never need to worry about spurious wakeups since you can notify on a specific condition ?

Regards,

Pho

[Henry Wong]

Originally posted by Pho Tek:

Can I say that using the new concurrent.locks primitives, one will never need to worry about spurious wakeups since you can notify on a specific condition ?

No... Being able to notify on a specific condition does remove having all of those notifications from notify all, but threading rules still apply.

It is possible that when you notify the one thread for the condition, that before the thread wakes up, yet another thread comes along and takes that condition. You should still check the condition everytime you wake up from a wait condition.

Remember that the lock needs to be released by the thread that sent the notification, and acquired by the thread that wakes up -- anything can happen in between, when the lock is freed.

Henry
[ December 01, 2007: Message edited by: Henry Wong ]

[Nicholas Jordan]

[HW:]It is possible that when you notify the one thread for the condition, that before the thread wakes up, yet another thread comes along and takes that condition. You should still check the condition everytime you wake up from a wait condition.

Is this the subtle race condition you mentioned quite aways back in another thread ? What this discussion here looks like is that synchronization primitives were not implemented in a "single execution path disallowing statement re-ordering" along with the implemtation of a JVM on uni-processor machines with proprietary schedulers that do not expect monitors to be needful of good reliability guarantees.

[Henry Wong]

Originally posted by Nicholas Jordan:

Is this the subtle race condition you mentioned quite aways back in another thread ? What this discussion here looks like is that synchronization primitives were not implemented in a "single execution path disallowing statement re-ordering" along with the implemtation of a JVM on uni-processor machines with proprietary schedulers that do not expect monitors to be needful of good reliability guarantees.

This has nothing to do with "statement reordering", or uni-processor vs multiprocessors. Basically, when a thread gives up a synchronization lock, there is nothing in the spec, that states that a particular waiting thread will get the lock.

And I also don't know what "subtle race condtion" from "another thread" are you referring to. Please clarify.

Henry

[Nicholas Jordan]

[HW:]   Please clarify

posted Monday, June 18, 2007 9:25 AM

wait() without notify()/notifyAll()

there is a really subtle race condition

Also, to clarifiy: Because nothing in the spec states that a particular particular waiting thread will get the lock when another thread wakes up, then checking ( I think ) becomes futile becuase anything can happen in between which introduces stochastic behaviour which seems naturally inconsistent with the rich sophistication of the Java Linguistic.
[ December 02, 2007: Message edited by: Nicholas Jordan ]

[Jim Yingst]

The race condition in the other thread was what would happen if wait() and notify() were not called from within synchronized code. Since Java requires that they must be called from code, that race condition becomes a non-issue.

[Nick]: Also, to clarifiy: Because nothing in the spec states that a particular particular waiting thread will get the lock when another thread wakes up, then checking ( I think ) becomes futile becuase anything can happen in between which introduces stochastic behaviour which seems naturally inconsistent with the rich sophistication of the Java Linguistic.

Checking is not futile; it's necessary. "Anything can happen between" sounds like a gross exaggeration which does nothing to clarify what you're talking about. What, exactly, do you think might happen that could render the check ineffective? What's a specific example of the sort of behavior you're worrying about here?

Note to original poster: please disregard this subsequent conversation between Nick and Henry and me; it is unlikely to help answer your original question at all, nor to shed any useful light on the matter. I believe the original question has been answered sufficiently already, but if not, please let us know.

[Nicholas Jordan]

It was the words: anything can happen in between, when the lock is freed., it's just the non-deterministic sound of that. Also, did you mean: Since Java requires that they must be called from synchronized code, ....?

[JY:]What, exactly, do you think might happen that could render the check ineffective? What's a specific example of the sort of behavior you're worrying about here?

What I am concerned with here is without strict critical section semantics, then matters like: It is possible that when you notify the one thread for the condition, that before the thread wakes up, yet another thread comes along and takes that condition. become possible and "Anything can happen between" is no longer a gross exaggeration. Also,"requires that they must be called from code" which does nothing to clarify whether wait() and notifiy() must be called from within synchronized code blocks. ( something which I never heard of, and would not use wait() anywhere on anything anyway )

It's just these gotcha's like Unfortunately, this isn't correct either and so on, my life experience forces me to notice minute details like this and it may be that Concurrent Programming with J2SE 5.0 is effective and robust.
[ December 03, 2007: Message edited by: Nicholas Jordan ]

[Jim Yingst]

[Nick]: Also, did you mean: Since Java requires that they must be called from synchronized code, ....?

Yes, the "synchronized" got dropped when I was editing, sorry.

[Nick]: What I am concerned with here is without strict critical section semantics, then matters like: It is possible that when you notify the one thread for the condition, that before the thread wakes up, yet another thread comes along and takes that condition. become possible and "Anything can happen between" is no longer a gross exaggeration.

Well, it's simply not true that anything can happen. There are specific things that can happen when a thread wakes up from wait(), and checking the condition takes care of those specific things. You seem to be imagining other unknown monsters under the bed. I can't address them without you being more specific. If you want more precise semantics about what can and cannot happen in multithreaded code, then see JLS 17.

[Nick]: Also,"requires that they must be called from code" which does nothing to clarify whether wait() and notifiy() must be called from within synchronized code blocks.

Addressed above, obviously.

[Nick]: ( something which I never heard of, and would not use wait() anywhere on anything anyway )

You've never heard of synchronized blocks? They're a standard Java feature. You would never use wait() or notify() on anything anyway? Then what is your purpose posting into this thread?
[ December 03, 2007: Message edited by: Jim Yingst ]

[Henry Wong]

Nick: It was the words: anything can happen in between, when the lock is freed., it's just the non-deterministic sound of that. Also, did you mean: Since Java requires that they must be called from synchronized code, ....?

By "anything can happen in between", let's narrow it down to, "some other thread acquires the lock in-between the lock free (of the notifier) and reacquire (by the waiting thread)". For this argument, let's assume the developer is *not* introducing a race condition here...

As for being non-deterministic, yes, it is... but so what? It doesn't mean that synchronization (or condition variables) is (are) broken -- it just means that you have to reconfirm the state when you wakeup, to see if you need to return to the wait condition.

This is true, and have always been true, with condition variables -- Solaris threads, POSIX threads, Windows threads, etc. all requires this.

Henry

[Nicholas Jordan]

[JY:]You've never heard of synchronized blocks? They're a standard Java feature. You would never use wait() or notify() on anything anyway? Then what is your purpose posting into this thread?

I have not studied the wait() an notifiy() semantics sufficiently, I got ahead of myself due to monsters in real-life ( stuff that gets thrown out of meaningless drivel for too much meaning - and is a really, really hard problem in general. ); My purpose posting into this thread is to narrow it down to, "some other thread acquires the lock in-between the lock free (of the notifier) and reacquire (by the waiting thread)" to determine that that doesn't mean that synchronization (or condition variables) is (are) broken so that I can see that it just means that you have to reconfirm the state when you wakeup - not that anything can happen in between would mean the term "undefined" -> i.o.w. it's simply not true that anything can happen.

In the long moderated view of my focus in posting to this thread is seeking strong guarantees that Any execution strategy that generates only allowed behaviors is an acceptable execution strategy. has been achieved in some jvm somewhere that I can identifiy unfailingly.