harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivanov, Alexey A" <alexey.a.iva...@intel.com>
Subject RE: [-SPAM-] RE: [classlib][swing] an odd code in swing
Date Wed, 06 Dec 2006 10:13:57 GMT
>-----Original Message-----
>From: Nathan Beyer [mailto:nbeyer@gmail.com]
>Sent: Wednesday, December 06, 2006 5:28 AM
>To: dev@harmony.apache.org
>Subject: Re: [-SPAM-] RE: [classlib][swing] an odd code in swing
>On 12/5/06, Thomas Hawtin <tackline@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
>> > marked as thread-safe.
>> This is a static mutable variables [bad]. In an environment where
>> 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?

Nathan, all,

All Swing implementation is *thread-unsafe*. This is clearly stated in
Javadocs and Swing tutorials. But there are several methods which are
explicitly marked as thread-safe in Javadoc. And only such methods are
guaranteed to be thread-safe.

Nothing is said about thread-safety in Timer doc, therefore in general
you should call its methods only from the Event Dispatch Thread.
Modifying timer object concurrently from several threads and even from
any non-ED Thread is considered unsafe. Swing Timer calls its listeners
on the EDT.


>> >> 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.
>> in this case volatile looks fine, and no-one would really notice if
>> 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.
>> >>    public static void setLogTimers(final boolean isLogTimers) {
>> >>        synchronized (Timer.class) {
>> >>            Timer.isLogTimers = isLogTimers;
>> >>        }
>> >>    }
>> Tom Hawtin

Alexey A. Ivanov
Intel Enterprise Solutions Software Division

View raw message