Book question on threads

[Ryan Stewart]

Reading a Java certification book, I came across this question:
"Which of these are plausible reasons why a thread might be alive, but still
not be running?
Select all valid answers.
a) The thread is waiting for some condition as a result of a call to wait().
b) The thread is waiting on a monitor for an object so that it may access a
certain member variable of that object.
c) The thread is not the highest priority thread and is currently not
granted CPU time.
d) The thread is sleeping as a result of a call to the sleep() method."

I said a, b, and d. The book says:
"a, b, c, and d
Note that only methods and code blocks can be specified as synchronized.
Variables cannot be declared as synchronized.Code blocks can be synchronized
on any object."

Their given reason seems to support my answer more than theirs. I'm thinking
typo. What do you think? What would your answer be?

 

[Carl Howells]

Reading a Java certification book, I came across this question:
"Which of these are plausible reasons why a thread might be alive, but still
not be running?
Select all valid answers.
a) The thread is waiting for some condition as a result of a call to wait().
b) The thread is waiting on a monitor for an object so that it may access a
certain member variable of that object.
c) The thread is not the highest priority thread and is currently not
granted CPU time.
d) The thread is sleeping as a result of a call to the sleep() method."

I said a, b, and d. The book says:
"a, b, c, and d
Note that only methods and code blocks can be specified as synchronized.
Variables cannot be declared as synchronized.Code blocks can be synchronized
on any object."

Their given reason seems to support my answer more than theirs. I'm thinking
typo. What do you think? What would your answer be?

It's true that their note doesn't address reason C. But reason C is
quite clearly valid. On any system that supports multiple threads,
decisions have to be made about which ones get to run at any given time.
Some OSes, especially real-time ones, will simply not run a given
thread for a rather significant chunk of time because there are threads
at higher priorities that the OS has determined need to be running instead.

 

[Ryan Stewart]

It's true that their note doesn't address reason C. But reason C is
quite clearly valid. On any system that supports multiple threads,
decisions have to be made about which ones get to run at any given time.
Some OSes, especially real-time ones, will simply not run a given
thread for a rather significant chunk of time because there are threads
at higher priorities that the OS has determined need to be running instead.

Uh oh... wait wait wait. Sorry, I mixed them up. I meant to say a, c, and d.
I wasn't paying attention. *slaps self about with a dead trout* I think the
answer should be a, c, and d, and that *B* is not a valid answer. Sorry
about that.

 

[Roedy Green]

c) The thread is not the highest priority thread and is currently not
granted CPU time.

This is by far the most common reason a thread is not running.

It applies even when you have no synchronisation or locking.

 

[Tony Morris]

Reading a Java certification book, I came across this question:
"Which of these are plausible reasons why a thread might be alive, but still
not be running?
Select all valid answers.
a) The thread is waiting for some condition as a result of a call to wait().
b) The thread is waiting on a monitor for an object so that it may access a
certain member variable of that object.
c) The thread is not the highest priority thread and is currently not
granted CPU time.
d) The thread is sleeping as a result of a call to the sleep() method."

I said a, b, and d. The book says:
"a, b, c, and d
Note that only methods and code blocks can be specified as synchronized.
Variables cannot be declared as synchronized.Code blocks can be synchronized
on any object."

Their given reason seems to support my answer more than theirs. I'm thinking
typo. What do you think? What would your answer be?

I agree with the book, and I don't understand your reasoning, so I can't
elaborate on why I think you are wrong - only that you are.

--
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]

This is by far the most common reason a thread is not running.

It applies even when you have no synchronisation or locking.

See my reply to the other post. I made a mistake in my original post. I
meant answer B, not C.

 

[Roedy Green]

a) The thread is waiting for some condition as a result of a call to wait().
b) The thread is waiting on a monitor for an object so that it may access a
certain member variable of that object.

All you have to do is declare a hunk of code synchronised or a method
synchronised, and automatically you wait in line for exclusive access
to the object, without any explicit calls to wait notify. So why
would not B be a good reason for a thread not to be running?

 

[xarax]

Uh oh... wait wait wait. Sorry, I mixed them up. I meant to say a, c, and d.
I wasn't paying attention. *slaps self about with a dead trout* I think the
answer should be a, c, and d, and that *B* is not a valid answer. Sorry
about that.

(b) the thread is WAITING for a monitor.

The operative phrase in the question is "not running", which
means that it is waiting for something. It is waiting because
of a call to wait(), or waiting for exclusive control of a
monitor (i.e., a synchronized block), or waiting for the
CPU, or waiting for a timer pop by calling sleep(). It is
waiting, which means it is not running.

 

[Ryan Stewart]

All you have to do is declare a hunk of code synchronised or a method
synchronised, and automatically you wait in line for exclusive access
to the object, without any explicit calls to wait notify. So why
would not B be a good reason for a thread not to be running?

Because you cannot exlicitly synchronize access to a member variable, or any
variable for that matter.

 

[Ryan Stewart]

(b) the thread is WAITING for a monitor.

The operative phrase in the question is "not running", which
means that it is waiting for something. It is waiting because
of a call to wait(), or waiting for exclusive control of a
monitor (i.e., a synchronized block), or waiting for the
CPU, or waiting for a timer pop by calling sleep(). It is
waiting, which means it is not running.

Read the rest of that answer: waiting on a monitor for an object so that it
may access a certain _member_variable_ of that object. You can't synchronize
access to a member variable.

 

[Tony Morris]

Uh oh... wait wait wait. Sorry, I mixed them up. I meant to say a, c, and d.
I wasn't paying attention. *slaps self about with a dead trout* I think the
answer should be a, c, and d, and that *B* is not a valid answer. Sorry
about that.

In that case, waiting for a monitor means the thread releases the CPU until
the monitor becomes available.
Even then, the thread might have to compete for the monitor and so still
might not acquire it.
It seems pretty clear cut to me - which part of that don't you understand?

--
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

 

[Ed Thompson]

The thread is waiting on a monitor for an OBJECT

But you can synchronize access to an object which would keep you from
accessing its member variables.

 

[Ryan Stewart]

In that case, waiting for a monitor means the thread releases the CPU until
the monitor becomes available.
Even then, the thread might have to compete for the monitor and so still
might not acquire it.
It seems pretty clear cut to me - which part of that don't you understand?

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.

 

[Ryan Stewart]

But you can synchronize access to an object which would keep you from
accessing its member variables.

How?

 

[Tony Morris]

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:

class X {
private int x;

public synchronized void setX(int x) {
this.x = x;
}
}

This is different to being able to explicitly synchronize the member
variable itself (which you can't do).

If two threads call setX in the above example, they will be competing for
the lock (which is the object that the method is called on), but only one
thread will acquire it - the other will wait, consuming no CPU, until the
mutually exclusive lock is acquired.

Is this the incorrect basis of your reasoning that answers your question?

--
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]

Sure you can synchronize access to a member variable:

class X {
private int x;

public synchronized void setX(int x) {
this.x = x;
}
}

This is different to being able to explicitly synchronize the member
variable itself (which you can't do).

If two threads call setX in the above example, they will be competing for
the lock (which is the object that the method is called on), but only one
thread will acquire it - the other will wait, consuming no CPU, until the
mutually exclusive lock is acquired.

Is this the incorrect basis of your reasoning that answers your question?

To me, that is not "synchronizing access to a member variable". Maybe I'm
just reading too much into the question. That's why I posted though. To see
what everyone thought about it. When I read the question, it gives me the
impression of something like this:

class X {
public synchronized int x;
}

Meaning that threads have to wait for access to x because it's synchronized.
However, as you and I and even the book point out, you can't do this.

 

[Andy Fish]

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

 

[Chris Smith]

To me, that is not "synchronizing access to a member variable". Maybe I'm
just reading too much into the question. That's why I posted though. To see
what everyone thought about it. When I read the question, it gives me the
impression of something like this:

class X {
public synchronized int x;
}

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".

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.

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?

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Nigel Wade]

Read the rest of that answer: waiting on a monitor for an object so that
it may access a certain _member_variable_ of that object. 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.

 

[Ryan Stewart]

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.