Re: Strange Socket problem

From:

Knute Johnson <nospam@knutejohnson.com>

Newsgroups:

comp.lang.java.programmer

Date:

Sat, 03 Mar 2012 17:59:34 -0800

Message-ID:

<jiuia6$ktc$2@dont-email.me>

On 3/3/2012 2:32 AM, x wrote:

Knute Johnson pisze:

On 3/2/2012 3:06 PM, Lew wrote:

I agree that the 'thread' variable's scope is wrong - it should be local
to 'start()', not an instance member. But at the moment that's not
causing any outright harm.

It's so I can start and interrupt the thread from a method call.

The volatiles exist because the methods that access them can be called
from other threads. I could have synchronized the start() stop()

Other threads... What are other threads allowed to do ?
You see, I'm really troubled by the public methods:

public void disconnect()
public void stop()
public boolean isConnected()

disconnect() is called by the main class to force a reload of the data
stop() is called my the main class exit routines
isConnected() is only called by disconnect() at the moment and will
probably disappear in the next minor rewrite

methods but not easily the socket variable in the run() method. I
thought it was cleaner to just use volatile.

But, the volatile keyword does not provide any kind of access control.
It just tells the JVM "hey, if this variable is changed by thread A, the
changed value must be visible for thread B, so don't cache it too
aggressively'.

Marcin Jaskolski

I know and I'm only using it for visibility in the methods when called
by another class.

--

Knute Johnson