>-----Original Message----- >From: Nathan Beyer [mailto:[EMAIL PROTECTED] >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 <[EMAIL PROTECTED]> 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. 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:[EMAIL PROTECTED] >> >> >> >> 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
