Well, I suppose it depends what you mean by "informed". If another thread has the lock on myObject, this thread won't be able to enter the synchronized block at first. So this thread will block, and it will not execute until the other thread exits its synhronized block and this thread acquires the lock. Behind the scenes, the JVM is managing process a bit. So you could say that the JVM has a list of threads that are trying to acquire the lock on myObject, and when that lock becmoes available, the JVM will "inform" one of those blocking threads, allowing it to execute.
However - this has nothing at all to do with notifyAll(). So I suspect it's not what you meant to ask about. In order for notifyAll() to have any significance, the thread must have already synchronized on myObject (as shown in your code) and then called the wait() method (not shown). If you call wait, the thread will wait until notified. If you don't call wait, then notification is irrelevant.
No - to do that, you need to call myObject.wait(). Which can only be done from inside code that is synchronized on myObject, such as you have shown. So you're partway there. But unless you actually call
"I'm not back." - Bill Harding, Twister
Live a little! The night is young! And we have umbrellas in our drinks! This umbrella has a tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss