Book question on threads

java-programmer, Book question on threads "Chris Smith" <email***@***.com> wrote in message
news:email***@***.com...
> 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.

java-programmer >> Book question on threads "Chris Smith" <email***@***.com> wrote in message
news:email***@***.com...
> 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.

java-programmer >> Book question on threads > 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

java-programmer >> Book question on threads Ryan Stewart wrote:
<snip>
> 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".

java-programmer >> Book question on threads "Tony Morris" <email***@***.com> wrote in message
news:ca88r1$k30$email***@***.com...
> > 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.
>
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
...
}

java-programmer >> Book question on threads On Wed, 09 Jun 2004 18:41:09 -0500, Ryan Stewart wrote:

> "Nigel Wade" <email***@***.com> wrote in message
> news:email***@***.com...
>> On Tue, 08 Jun 2004 20:09:53 -0500, Ryan Stewart wrote:
>> > You can't
>> > synchronize access to a member variable.
>>
>> You most certainly can synchronize *access* to a member variable, and in
>> most circumstances it is essential that you do so.
>>
>> If the member variable is public you cannot *enforce* synchronization, but
>> any thread accessing the variable should synchronize on some object (and
>> they all must use the *same* object). Typically the synchronization
>> object would be the object which contains the variable in question, but it
>> doesn't have to be.
>>
>> To enforce synchronization on the variable you would need to make it
>> private, and declare getter/setter methods which were synchronized.
>>
> 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, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : email***@***.com
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555

java-programmer >> Book question on threads On Wed, 09 Jun 2004 18:41:48 -0500, Ryan Stewart wrote:

> "Andy Fish" <email***@***.com> wrote in message
> news:TZCxc.1995$O%email***@***.com...
>> "Tony Morris" <email***@***.com> wrote in message
>> news:ca6099$gvq$email***@***.com...
>> > > The part about a thread waiting to access a member variable. Why
>> > > would
> a
>> > > thread be waiting on a monitor for the purpose of accessing a
>> > > member variable? You can't synchronize access to a variable.
>> > >
>> > >
>> > >
>> > Sure you can synchronize access to a member variable:
>> >
>> >
>> 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.

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.

--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : email***@***.com
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555

java-programmer >> Book question on threads "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" <email***@***.com> wrote in message
news:email***@***.com...
> "Tony Morris" <email***@***.com> wrote in message
> news:ca88r1$k30$email***@***.com...
> > > 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.
> >
> 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
> ...
> }
>
>

java-programmer >> Book question on threads "Nigel Wade" <email***@***.com> wrote in message
news:email***@***.com...
> 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.

java-programmer >> Book question on threads On Thu, 10 Jun 2004 18:44:58 -0500, Ryan Stewart wrote:

> "Nigel Wade" <email***@***.com> wrote in message
> news:email***@***.com...
>> 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.
>
>

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, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : email***@***.com
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555

java-programmer >> Book question on threads On Thu, 10 Jun 2004 18:44:58 -0500, Ryan Stewart wrote:

> "Nigel Wade" <email***@***.com> wrote in message
> news:email***@***.com...
>> 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.

Yes.

>> The second case is using a
>> synchronized method.
>>
> 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.

--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : email***@***.com
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555