Re: threadpool and ui paint
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