aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes not synchronizing on an object with wait Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "not synchronizing on an object with wait" Watch "not synchronizing on an object with wait" New topic
Author

not synchronizing on an object with wait

Rachel Glenn
Ranch Hand

Joined: Oct 24, 2012
Posts: 95
Suppose I have this code:


I know the code is wrong because the call to wait must be within synchronized context. But why doesn't the compiler complain? why does this generate an exception instead?
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2853
    
  11

Did you try to compile it? What error message did you get? You can't use void in the parameter list. If you don't have any parameters, just leave the parentheses empty.
Rachel Glenn
Ranch Hand

Joined: Oct 24, 2012
Posts: 95
Greg Charles wrote:Did you try to compile it? What error message did you get? You can't use void in the parameter list. If you don't have any parameters, just leave the parentheses empty.


oops...that is the c++ programmer coming out in me to put void in the parameter list...

this was from a mock exam question.... I was more interested from a theory point of view....
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Rachel Glenn wrote:Suppose I have this code:


I know the code is wrong because the call to wait must be within synchronized context. But why doesn't the compiler complain? why does this generate an exception instead?


Supposed that you have this code...



Doesn't this make the code you have correct? (with the void part fixed, of course)

Henry

Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Rachel Glenn
Ranch Hand

Joined: Oct 24, 2012
Posts: 95
Henry Wong wrote:
Rachel Glenn wrote:Suppose I have this code:


I know the code is wrong because the call to wait must be within synchronized context. But why doesn't the compiler complain? why does this generate an exception instead?


Supposed that you have this code...



Doesn't this make the code you have correct?

Henry


ok, let me type in the full example:




Here are the possible answers:

A. The code will not compile because of an error in line 12 of class Foo
B. The code will not compile because of an error in line 7 of class Foo
C. The code will not compile because of an error in line 4 of class Test
D. The code will not compile because of some other error in class Test
E. an exception occurs at runtime
F. x is 5 x is 6


The stated answer is: E is correct because the thread does not own the lock of the object it invokes wait() on. If the method were synchronized, the code would run without exception.

Sooo...I take this to mean that on line 7 of class Foo, since the call to wait() is not synchronized, the exception will be thrown. But why doesn't the compiler complain about this? Why does it leave this to get handled during runtime??
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Rachel Glenn wrote:
ok, let me type in the full example:




Here are the possible answers:

A. The code will not compile because of an error in line 12 of class Foo
B. The code will not compile because of an error in line 7 of class Foo
C. The code will not compile because of an error in line 4 of class Test
D. The code will not compile because of some other error in class Test
E. an exception occurs at runtime
F. x is 5 x is 6


The stated answer is: E is correct because the thread does not own the lock of the object it invokes wait() on. If the method were synchronized, the code would run without exception.

Sooo...I take this to mean that on line 7 of class Foo, since the call to wait() is not synchronized, the exception will be thrown. But why doesn't the compiler complain about this? Why does it leave this to get handled during runtime??


Please QuoteYourSources...

Henry
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Rachel Glenn wrote:
The stated answer is: E is correct because the thread does not own the lock of the object it invokes wait() on. If the method were synchronized, the code would run without exception.

Sooo...I take this to mean that on line 7 of class Foo, since the call to wait() is not synchronized, the exception will be thrown. But why doesn't the compiler complain about this? Why does it leave this to get handled during runtime??


Simply, the compiler doesn't complain because the compiler can't tell that it is an issue at compile time. It is perfectly valid for a thread to already own the lock prior to calling the method, so it may be okay for the method to not need to grab the lock again. And there is no way for the compiler to know that... as shown in the example that I provided.

In other words, run the example that I provided... you will see that it compiles fine, and runs fine without any exceptions.

Henry
Rachel Glenn
Ranch Hand

Joined: Oct 24, 2012
Posts: 95
My source for this code is mock exam 3 of sierra/bates.

I thought that EVERY call to wait must be within synchronized context. So, in the example that I provided, couldn't the compiler have seen that the method that the wait() call was made in was not synchronized, nor was the call to wait() within a synchrnozed block?

Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Rachel Glenn wrote:
I thought that EVERY call to wait must be within synchronized context. So, in the example that I provided, couldn't the compiler have seen that the method that the wait() call was made in was not synchronized, nor was the call to wait() within a synchrnozed block?


Short Answer:

The compiler follows the rules of the Java Language Specification. There are *no* rules related to the wait() method that requires special handling (or error reporting) by the compiler.


Longer Answer (with a somewhat sarcastic example ):

Here is a scenario...

1. You write a class that has your method.

2. You go on vacation for a week.

3. You write a new class that instantiates your previous class, grabs the synchronized lock on it, and then call your first class.


Based on your theory, the compiler should complain about the first class, but then what? When it compiles the second class, it is supposed to go back and compile the first class (since it is now okay) ?

Henry
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: not synchronizing on an object with wait