harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@gmail.com>
Subject Re: [-SPAM-] RE: [classlib][swing] an odd code in swing
Date Thu, 07 Dec 2006 03:01:05 GMT
On 12/6/06, Ivanov, Alexey A <alexey.a.ivanov@intel.com> wrote:
> >-----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
> 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?
>
> 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.

Do you know of any specific examples of code that's required to be thread safe?

Other parts of the RI spec (the javadoc) aren't very good at
documenting all of the areas that are thread safe or the specifics of
it.

-Nathan

>
> 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.
>
>
> Regards,
> Alexey.
>
> >
> >>
> >> >> 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
> >>
>
> --
> Alexey A. Ivanov
> Intel Enterprise Solutions Software Division
>

Mime
View raw message