Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28457

Re: threadpool and ui paint

Show all headers | View raw

On 5/13/2014 12:45 PM, markspace wrote:
>
> This is broken if Thing or Collection is modifiable.
>
> On 5/13/2014 5:10 AM, Eric Sosman wrote:
>
>>      final Collection<Thing> finished = ...;
>>      SwingUtilities.invokeLater(new Runnable() {
>>          @Override
>>          public void run() {
>>              for (Thing x : finished) {
>>                  x.updateTheDisplay();
>>              }
>>          }
>>      });
>
>
> The following would work, if you can guarantee that no Thing are being
> changed while the invokeLater is running.  Maybe use invokeNow instead
> to make the update on the EDT synchronous.

     I think you mean SwingUtilities.invokeAndWait().  But yes: If the
Thing or the collection of Things is being changed while other parts
of the program are trying to capture "the" state of affairs, there'll
be nothing but trouble.

>      final Collection<Thing> finished =
> Collections.synchronizedCollection( new Collection() );
>      try { SwingUtilities.invokeNow(new Runnable() {
>          @Override
>          public void run() {
>              for (Thing x : finished) {
>                  x.updateTheDisplay();
>              }
>          }
>      });
>      } catch( Exception ex ) {}
>
> However if you have another thread besides these two that is updating
> Thing asynchronously then this fails.  You must also synchronize the
> Thing object itself in that case.

     I don't think using synchronizedCollection() helps here.  It will
ensure that individual actions on the collection are atomic, but will
not atomize (?!) sequences of actions.  In particular, you can still
get a ConcurrentModificationException.

> Without a thorough understanding of threading and the Java memory model
> copying by rote is fraught with error.  One shouldn't be doing this sort
> of thing unless one is an expert, or you're just plain going to make
> broken code.

     This is yet another motivation for dividing the Thing into a model
and a view thereof: It becomes easier to ensure that multiple viewers
always see the Thing in a consistent state, even if that state is
mutable and mutating.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

threadpool and ui paint Philipp Kraus <philipp.kraus@flashpixx.de> - 2014-05-13 09:35 +0200
  Re: threadpool and ui paint Joerg Meier <joergmmeier@arcor.de> - 2014-05-13 11:26 +0200
    Re: threadpool and ui paint markspace <markspace@nospam.nospam> - 2014-05-13 09:35 -0700
  Re: threadpool and ui paint Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-05-13 08:10 -0400
    Re: threadpool and ui paint markspace <markspace@nospam.nospam> - 2014-05-13 09:45 -0700
      Re: threadpool and ui paint Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-05-13 13:22 -0400
        Re: threadpool and ui paint markspace <markspace@nospam.nospam> - 2014-05-13 10:46 -0700

csiph-web