On 3/2/2012 4:00 PM, Lew wrote:
Knute Johnson wrote:
The volatiles exist because the methods that access them can be called
from other threads. I could have synchronized the start() stop()
methods but not easily the socket variable in the run() method. I
thought it was cleaner to just use volatile.
I see a problem right there.
public void disconnect() {
if (isConnected())
if (socket != null)
try {
socket.close();
} catch (IOException ioe) {
ioe.printStackTrace();
}
}
Since these are controlled by separate synchronization (different
'volatile' variables) there's a race condition trying to work with both
at once.
I don't think so.
Also, 'socket' can become 'null' between the check for not 'null' and
the 'close()' call.
Only if I set it to null and I don't. That is there so that if the
Socket doesn't make the first connection when disconnect() is called
that I won't get a NPE.
You need to synchronize with 'synchronized' or other strong mechanism.
I don't think so and here's why; isConnected only gets modified by one
thread and read by another, socket is only modified by one thread and
read by another. In the disconnect() method, as soon as isConnected()
is called, isConnected the volatile variable is read and that would make
socket current even if it weren't volatile which it is but I didn't want
to rely on side effects in case I changed code somewhere.
Anyway, disconnect() isn't getting called in this situation so it's not
causing my problem.
I really appreciate everybody looking at this. I've got a couple of
ideas of where to code some traps and I'll have to put those in one
night and see what happens.
gregorie. | Essex, UK