Re: [-SPAM-] RE: [classlib][swing] an odd code in swing

[Thomas Hawtin <ta...@tackline.plus.com>]

Ivanov, Alexey A wrote:
> I think synchronized block can be safely removed.
> Any way Swing is not thread-safe, and these methods are not explicitly
> marked as thread-safe.

This is a static mutable variables [bad]. In an environment where there 
are multiple 'AppContexts', such as Applets, it may be accessed by 
multiple threads.

>> From: Mikhail Loenko [mailto:mloenko@gmail.com]
>>
>> javax.swing.Timer
>>
>> this is an attomic operation, why synchronized?

That is not a valid argument.

One issue is that the change would not necessarily visible to other 
threads if not synchronized/volatile. Secondly, if there are other 
non-atomic operation using synchronized, then these may fail. However, 
in this case volatile looks fine, and no-one would really notice if even 
that was not present.

>>    public static void setLogTimers(final boolean isLogTimers) {
>>        synchronized (Timer.class) {
>>            Timer.isLogTimers = isLogTimers;
>>        }
>>    }

Tom Hawtin

Re: [-SPAM-] RE: [classlib][swing] an odd code in swing

[Nathan Beyer <nb...@gmail.com>]

On 12/5/06, Thomas Hawtin <ta...@tackline.plus.com> wrote:
> Ivanov, Alexey A wrote:
> > I think synchronized block can be safely removed.
> > Any way Swing is not thread-safe, and these methods are not explicitly
> > marked as thread-safe.
>
> This is a static mutable variables [bad]. In an environment where there
> are multiple 'AppContexts', such as Applets, it may be accessed by
> multiple threads.

I've seen other unprotected (not synchronized) bits of code like this
that would seemingly need to be syncrhonized. I know the UI portions
of Swing must be thread isolated, but we can't assume that the
low-level services of Swing will be thread isolated, correct?

>
> >> From: Mikhail Loenko [mailto:mloenko@gmail.com]
> >>
> >> javax.swing.Timer
> >>
> >> this is an attomic operation, why synchronized?
>
> That is not a valid argument.
>
> One issue is that the change would not necessarily visible to other
> threads if not synchronized/volatile. Secondly, if there are other
> non-atomic operation using synchronized, then these may fail. However,
> in this case volatile looks fine, and no-one would really notice if even
> that was not present.

Technically speaking, volatile would work, but I would lobby for
keeping it synchronized, as it will guarantee the atomicity and
ordering. Also, volatile has been notoriously incorrectly implemented
in VMs, as the memory model for the VM has only been completely
defined since Java 5.

Good comments though. Java concurrency is a largely misunderstood
concept. If anyone's looking for a good book on it, Java Concurrency
in Practice is a great read.

-Nathan

-Nathan

>
> >>    public static void setLogTimers(final boolean isLogTimers) {
> >>        synchronized (Timer.class) {
> >>            Timer.isLogTimers = isLogTimers;
> >>        }
> >>    }
>
> Tom Hawtin
>