On 12/6/06, Ivanov, Alexey A <[EMAIL PROTECTED]> wrote:
>-----Original Message-----
>From: Nathan Beyer [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, December 06, 2006 5:28 AM
>To: [email protected]
>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.
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:[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
