Book question on threads

[Ryan Stewart]

I think there is a bit of confusion caused by the explanation passage in the
book. What the book is saying is that access to variables is not
automatically synchronized. answer B means that someone has written some
code to sychronize

If that's what it means then why doesn't it say so? I find the question
ambiguous at best.

 

[Ryan Stewart]

Obviously, it's possible to interpret the question in a way that makes
this answer wrong; it's probably easier, though, to interpret it to make
this answer right. What you've listed is invalid syntax, and I would
have a rather strong bias against an interpretation of this question
that requires you to assume (without seeing code) that the author has
written code that results in compile-time errors. If that were the
case, option B should read "the thread was never started because the
program didn't compile".

The example had no code. Only the question which I posted. The whole point
of the question though, is to determine which possibilities are... um...
possible.

To take a guess at a literal explanation, should we assume the author is
being as literal as you are, the word "access" is very closely related
to "accessor", the word for a short method that serves to allow someone
to access a field. More likely, though, the author wasn't excluding
non-direct access to the variable; the last phrase should instead be
interpreted as a statement of intent for what the thread wants to do.

As I said in my reply to Nigel, questions about programming (similar to
programs about science and math) are very clear-cut. If every word of an
answer isn't true, the answer is incorrect. At least that's how it is in my
experience.

In the end, when people so frequently post bad questions from
certification prep books, and it's so widely known that a large majority
of certification prep books are full of stupid drivel from people who
confuse the Java language with their own pet mental gymnastics for
memorizing stuff and possibly also just feel more secure when they ask
ambiguous questions so that you'll miss some... given all this, why
would it be a surprise that someone found an ambiguous question in a
Java certification prep book?

No surprise. I just wanted to see if this was indeed one of those ambiguous
questions. Apparently it is. If I saw this question on an actual test, I
think I'd still answer it as I have here, because I haven't really heard a
convincing explanation why not to. It seems that every response either
explicitly or implicitly has something to do with "interpreting the answer"
to mean something slightly different from what it says. I'm still going to
have to stand by my original response to the question: you cannot
synchronize access to a variable. Therefore a thread will never need an
object's monitor in order to access a member variable of that object.
Therefore, a thread will never be waiting on said monitor.

 

[Tony Morris]

No surprise. I just wanted to see if this was indeed one of those
ambiguous

questions. Apparently it is. If I saw this question on an actual test, I
think I'd still answer it as I have here, because I haven't really heard a
convincing explanation why not to. It seems that every response either
explicitly or implicitly has something to do with "interpreting the answer"
to mean something slightly different from what it says.

I disagree.
The question is not ambiguously worded.
Please provide an alternative of "access a certain member variable of that
object" that is not an accessor, mutator, or similar, but still demonstrates
an ambiguity.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Sudsy]

Ryan Stewart wrote:

As I said in my reply to Nigel, questions about programming (similar to
programs about science and math) are very clear-cut. If every word of an
answer isn't true, the answer is incorrect. At least that's how it is in my
experience.

<snip>

I had a "technical interview" last Saturday and the interviewer and I
were apparently on different wavelengths. She had specific answers in
mind but I was having difficulty understanding the questions. I would
have LOVED a white-board problem. Instead, I was asked questions like
"In JSP, how do you declare classes?"
The answer she was looking for was the "<%!" construct.
Perhaps y'all would have figured out what was being asked.
Perhaps (almost certainly if you'd recently taken the certification)
you would have been able to list all the methods in java.lang.Object.
But how do you respond to "what methods are defined in the Serializable
interface?"
Is the interviewer curious as to whether you know about the writeObject
and readObject methods?
So things aren't always so "cut and dried".

 

[Ryan Stewart]

I disagree.
The question is not ambiguously worded.
Please provide an alternative of "access a certain member variable of that
object" that is not an accessor, mutator, or similar, but still demonstrates
an ambiguity.

Now I'm not sure what *you're* saying... an alternative to the phrase? an
alternative method? Either way I look at your request, I can't make sense of
it. A thread might wait to access a method. A thread will not ever wait to
access a variable. In other words:
class X {
static int x;
static int synchronized doSomething() {}
}

class ThreadedClass {
....
System.out.println(X.x); // A thread executing this line will never
block
System.out.println(X.doSomething()); // A thread executing this line
might block
....
}

 

[Nigel Wade]

But that's it exactly. As you describe it, the thread is waiting to access a
method, not a variable. As Chris pointed out elsewhere, I may just be
pulling at straws, but this is a question on programming, and if every word
isn't correct, then the whole answer is wrong. This question still seems
ambiguous to me. Obviously it doesn't to anyone else that's responded thus
far.

No. I've describe *both* cases. The first case is using an object's
monitor to synchronize access to the variable. The second case is using a
synchronized method.

 

[Nigel Wade]

If that's what it means then why doesn't it say so? I find the question
ambiguous at best.

The question isn't ambiguous, neither is the answer, if you understand
synchronization. From your posts its clear that you are missing a clear
understanding of this, so I'll try to explain it.

First of all, lets go back to the original question, and the answer you
don't like.

"Which of these are plausible reasons why a thread might be alive, but
still not be running?"
b) The thread is waiting on a monitor for an object so that it may access
a certain member variable of that object.

The answer is clearly true. A thread *may* block waiting on a monitor for
an object. The fact that the answer says it's to "access a member
certain member variable" is there to put it into a real-world context.
It's also true that the thread doesn't have to block on that
synchronization object, it can just go ahead and access the member
variable (with all the bad consequences).

"Variables cannot be declared as synchronized." is also true. That is why
access is synchronized on the object itself, because the member variable
*cannot* be declared synchronized.

To explain, let's look at a very simple example.

Suppose we have a class :

class CountClass {
int count;
}

Now, further suppose we have a multi-threaded application with 2 threads
running, and that an instance of CountClass exists called total, which is
accessible to both threads.

Each thread wants to increment total.count, and uses this code:

total.count += 1;

which may look harmless enough but there's a serious problem lurking in
the background waiting to bite you when you least expect it.

What actually happens is that the value of total.count is taken from
memory into a register, the register is incremented and then written back
to memory. This happens in both threads.

If this bit of code runs in thread 1 first, followed by thread 2 there is
no problem, and count gets incremented by 2. But, threads are meant to be
able to run synchronously, and this is where the problem lies. If thread
1 loads total.count into a register and then thread 2 also loads it, but
before thread 1 has incremented and written it back, then they will both
generate the same result and total.count will be incremented by 1 rather
than 2.

What is necessary is to synchronize access to this member variable so
only 1 thread can update it. The simplest way would be to declare it as
synchronized:

synchronized int count;

but this isn't allowed, as stated in the answer, so we need another
mechanism.

Every object has a monitor which can be used for synchronization. What the
code ought to do is synchronize access to the object's member variable
using the object's monitor :

synchronized( total ) {
total.count += 1;
}

this is what b) refers to. Access to the member variable total.count is
being synchronized on total's monitor.

There are alternatives to this. You can synchronize on any object's
monitor, it doesn't have to be the object whose member variable you are
accessing:

synchronized( anotherObject ) {
total.count += 1;
}

would work just as well.


Also, you could protect count, and provide access via a syncrhonized
method:

class CountClass {
private int count;

public synchronized incrementCount() {
count += 1;
}
}

then in the thread, use the call :

total.incrementCount();

this is doing pretty much the same as the first alternative, as the method
incrementCount is synchronized on total's monitor.

 

[Tony Morris]

"Accessing a variable" is defined like this.

Here "x is accessed":

class Y {
public int getX() {
return x;
}
}

Client code:
new Y().getX();

One might argue that the following is "accessing a variable":

class Y {
public int x;
}

Client code:
new Y().x;

I retract my statement that there is no possibility for ambiguity.
However, I made the assumption (as does the book I suspect), that correct OO
practices are followed such that "accessing a variable" only ever happens
via a method.
A stern man with a wooden stick would enforce this, but not the compiler, so
the question becomes:
Is "accessing a variable" defined by how a stern man with a wooden stick
defines it, or how the compiler defines it?
If the JLS contains a concise definition of "accessing a variable", then I
believe this would answer the question, and no ambiguity is present.

If you are studying for the SCJP exam, you will not encounter these types of
questions. There is a post somewhere on this thread (lost it now) that gives
a very clear definition of the content of exam study books.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Ryan Stewart]

No. I've describe *both* cases. The first case is using an object's
monitor to synchronize access to the variable.

To me, this is a thread waiting on a monitor to enter a synchronized block
of code.

The second case is using a
synchronized method.

And this is a thread waiting on a monitor to access a method. In neither of
these cases is the thread waiting for access to a variable. But again,
that's just me.

 

[Nigel Wade]

To me, this is a thread waiting on a monitor to enter a synchronized
block of code.

Exactly.

Example b) is what happens when another thread holds the monitor. This
thread will wait on the monitor, and is therefore alive but not running.
When the other thread releases the monitor this thread will enter the
synchronized block and can access the object's member variable safely.

 

[Nigel Wade]

To me, this is a thread waiting on a monitor to enter a synchronized
block of code.
Yes.


And this is a thread waiting on a monitor to access a method.
Yes.

In neither of
these cases is the thread waiting for access to a variable. But again,
that's just me.

They could be. In case b) the thread is blocked waiting for the object's
monitor, and so it is a valid reason for the thread not to be running.
That the thread wants the monitor to safely access a member variable is
just added information for the sake of reality.