[concurrency-interest] SwingWorker a special producer/consumer

Joe Bowbeer joe.bowbeer at gmail.com
Fri Jun 2 09:30:01 EDT 2006


On 6/2/06, Rémi Forax <forax at univ-mlv.fr> wrote:
>
> The bug is due to the fact that there is no way to generate an array of
> T without explicitly indicate the class of T.
>
> One way to correct the bug is to change the signature of the run method
> to run(List<T> args) or run(Queue<T> args).
> In this case, its perhaps interresting to use a thread safe collection.
>

I think safe coding practices would dictate that the elements be
copied on their way into the AccumulativeRunnable from SwingWorker's
publish(V... chunks) method.

Likewise, I think safe coding practices would dictate that the
elements be copied on their way out of the AccumulativeRunnable into
SwingWorker's process(V... chunks) method.

The still leaves the question of whether AccumulativeRunnable
could/should use a concurrent collection instead of an externally
synchronized collection.

Attempting this in the most straightforward way would require that the
concurrent collection support atomic bulk operations such as
addAll(list) and drainTo(list), but the addAll method is not atomic
(AFAIK) and there is no drainTo method...

--Joe

On 6/2/06, Rémi Forax <forax at univ-mlv.fr> wrote:
> Joe Bowbeer a écrit :
>
> >On 6/2/06, Rémi Forax <forax at univ-mlv.fr> wrote:
> >
> >
> >>The question is what is the best concurrent data structure
> >>for this job.
> >>
> >>
> >>
> >
> >I'm looking at the source at https://swingworker.dev.java.net/
> >
> >
> it seems to be the same code.
>
> >Is this sufficiently current?
> >
> >
> >If so, SwingWorker enqueues AccumulativeRunnable instances on the AWT
> >EventQueue by way of the SwingUtilities.invokeLater() method.
> >
> >AccumulativeRunnable holds the accumulated arguments in an
> >ArrayList<T> and synchronizes internally.  So there's no need to pass
> >a thread-safe data structure to the process() method -- because
> >thread-safety is already handled by the SwingWorker internals.
> >
> >I interpret the details as:
> >
> >When the submitted runnable is executed on the event thread, it grabs
> >the existing elements from the internal ArrayList and calls the
> >run(T... args) method.  These elements are grabbed by the flush()
> >method.  The elements were added by the add() method.  Both methods
> >are synchronized.  In this way one or more process(V... chunks) calls
> >on the worker thread translate into a single run(T... args) call on
> >the event thread.
> >
> >
> yes
>
> >Are you proposing removing the synchronization from
> >AccumulativeRunnable and replacing it with some kind of thread-safe
> >collection?
> >
> >
> Yes.
> The bug is due to the fact that there is no way to generate an array of
> T without
> explicitly indicate the class of T.
>
> One way to correct the bug is to change the signature of the run method
> to run(List<T> args) or run(Queue<T> args).
> In this case, its perhaps interresting to use a thread safe collection.
>
> In perhaps it's a bad idea, i don't know, that why i ask for experts.
>
> Rémi Forax
>



More information about the Concurrency-interest mailing list