Exam 9, Q24 Dan Chisholm

[Dan Culache]

Question 24
A Thread can become the owner of an object's monitor by which three of the following?
a. By invoking the sleep method on the Thread.
b. By entering any synchronized static method of the Thread class.
c. By blocking on IO.
d. By entering a synchronized instance method.
e. By invoking the wait method on the Object.
f. By entering the body of a block that is synchronized on the Object.
g. By entering a synchronized static method of a class of type Class.
h. By invoking the notify method on the Object.
i. None of the above.
Answers:
d. By entering a synchronized instance method.
f. By entering the body of a block that is synchronized on the Object.
g. By entering a synchronized static method of a class of type Class.
I believe that the answer is f ONLY.
d. By entering a synchronized instance method.
This is ambiguous. I could enter a synchronized instance method of a different object. A correct option might be "By entering a synchronized instance method of the object"
g. By entering a synchronized static method of a class of type Class.
Is this correct? According to the Java language specification "A class method that is declared synchronized (�8.4.3.6) synchronizes on the lock associated with the Class object of the class." and there is only one Class object associated with each class type.
Having g as a correct answer would imply that entering a synchronized class method will lock all the objects of that type. Could that be true?
To me it makes sense (that g is not true) since a static method cannot access instance variables. If there is no object instantiated of that class only the Class object of that class what object would get locked?
In the code below I'm locking the at object in the run() method but AT.lockClass can still run so it's not seeking a lock on at. I don't think that two synchronized blocks of code can lock the same object at the same time.

package s11;
public class T_Thread {
public static void main(String[] args) {
MyThread t = new MyThread();
t.start();      // 1
AT.lockClass(); // 2
}
}
class AT {
private int x=11;
static private int y=11;
public int x() {return x--;}
static synchronized void lockClass() {
try {
do {
System.out.println("Class lock");
Thread.yield();
Thread.sleep(1000); }
while (y-->0);
}
catch (InterruptedException e) {}
}
}
class MyThread extends Thread {
public void run() {
AT at = new AT();
synchronized (at) {
try {
do{
System.out.println("Object lock");
Thread.yield();
Thread.sleep(1000); }
while (at.x()>0);
}
catch (InterruptedException e) {}
}
}
}
//output -------------------
Class lock
Object lock
....
Class lock
Object lock

Am I right or I am missing something???
[ February 13, 2003: Message edited by: Dan Culache ]

[Thomas Paul]

I agree with your interpretation.

[Dan Chisholm]

Thank you for using my exam.

Question 24
A Thread can become the owner of an object's monitor by which three of the following?
a. By invoking the sleep method on the Thread.
b. By entering any synchronized static method of the Thread class.
c. By blocking on IO.
d. By entering a synchronized instance method.
e. By invoking the wait method on the Object.
f. By entering the body of a block that is synchronized on the Object.
g. By entering a synchronized static method of a class of type Class.
h. By invoking the notify method on the Object.
i. None of the above.

Answer option 'd' suggests that the following is a true statement.

A Thread can become the owner of an object's monitor by entering a synchronized instance method.

I think that it can be implicitly understood that the instance method is indeed a member of the class in question. In order to make a more explicit statement it would be necessary to say something like the following.

A Thread can become the owner of an object's monitor by entering a synchronized instance method that is a member of the object in question.

I'm not sure that the longer version is more helpful than the shorter version.

[Dan Culache]

Hi Dan, thanks for putting the exams out. Helpful!! The drawback is that you have to take complaints from nitpickers like me.
About option d, it definitely tricked me. Maybe you could say something like "A Thread can become the owner of an object's monitor by entering a synchronized instance method of the object."
But if nobody else complained I guess you could leave it like this.
But what I really am curious about is option g.

[Dan Chisholm]

A Thread can become the owner of an object's monitor...?
g. By entering a synchronized static method of a class of type Class.

This is a special case that applies to entering a static method of the Class class. If you invoke getClass on an instance of Class then you get back the same instance. For example, the following program prints the value "true".

class Y {
  public static void main(String[] args) throws ClassNotFoundException {
    Class c1 = Class.forName("java.lang.Class");
    Class c2 = c1.getClass();
    System.out.println(c1 == c2);
  }
}

If a thread invokes a static method on c1 then it will obtain the lock on the instance c1.
I think that answer option g is beyond the scope of the real exam so I think that I will remove it.

[Dan Chisholm]

Dan,
Do you like this new version of the question?

A Thread can become the owner of an object's monitor by which two of the following? Please assume the object is not an instance of type Class.
a. By invoking the sleep method on the Thread.
b. By blocking on IO.
c. By entering a synchronized instance method of the Object.
d. By invoking the wait method on the Object.
e. By entering the body of a block that is synchronized on the Object.
f. By entering a synchronized static method of the Object.
g. By invoking the notify method on the Object.
h. None of the above.

The correct answers would be 'c' and 'e'.

[Pradeep bhatt]

Hi Dan,
I understand When the Class object of an object
is obtained and then the static sychronized method is invoked ..In effect the "class" lock (not the instance)lock is obtained.
Let me know in case I am wrong.

Originally posted by Dan Chisholm:

class Y {
  public static void main(String[] args) throws ClassNotFoundException {
    Class c1 = Class.forName("java.lang.Class");
    Class c2 = c1.getClass();
    System.out.println(c1 == c2);
  }
}

If a thread invokes a static method on c1 then it will obtain the lock on the instance c1.
I think that answer option g is beyond the scope of the real exam so I think that I will remove it.

[Dan Chisholm]

Originally posted by Pradeep Bhat:
Hi Dan,
I understand When the Class object of an object
is obtained and then the static sychronized method is invoked ..In effect the "class" lock (not the instance)lock is obtained.
Let me know in case I am wrong.

Pradeep,
Suppose that a program uses an instance of a class of type X. When class X is loaded an instance of type Class is associated with class X. For example, the X.getClass method will return a reference to the instance of type Class that is associate with type X.
There is only one instance of type Class that is associated with every instance of type X. When a synchronized static method is invoked on X then the lock on the Class instance is acquired.
Just as an instance of type Class is associated with type X, an instance of type Class is associated with type Class. For that particular instance of type Class the lock associated with the instance methods and static methods is the same.
As I mentioned earlier, this is beyond the scope of the real exam and it will be removed from my mock exam.

[Dan Culache]

Dan, the question looks just fine. I'm glad I could help.
Now about that option beyond the scope of the real exam. It's probably good to take it out but I believe you have something there. If you change the order of lines 1 and 2 there, actually if the static method gets to run first it seems like you get a behavior consistent with the intent of the question.
I mean the output is
Class lock
Class lock
..
Class lock
Object lock
Object lock
..
Object lock
But not if it's the other way around. Weird.