Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Knute Johnson <nospam@knutejohnson.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Strange Socket problem
Date: Sat, 03 Mar 2012 17:59:34 -0800
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <jiuia6$ktc$2@dont-email.me>
References: <jiojsa$5ol$1@dont-email.me> <4f512b27$0$26687$65785112@news.neostrada.pl> <jirjpg$rkb$1@news.albasani.net> <jirlma$bfm$1@dont-email.me> <4f51f338$0$1256$65785112@news.neostrada.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 4 Mar 2012 01:59:34 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="mz/LDSJwiWnk3Jnnqg7x+Q"; logging-data="21420"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+C1OjlT+BKcckVFuvEaI+d"
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
In-Reply-To: <4f51f338$0$1256$65785112@news.neostrada.pl>
Cancel-Lock: sha1:TXUdlv0jtOzLfyfWWwc1Pg1wxKQ=
Xref: csiph.com comp.lang.java.programmer:12636

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