[concurrency-interest] j.u.c/backport performance on Windows

Peter Kovacs peter.kovacs.1.0rc at gmail.com
Tue Apr 3 09:41:35 EDT 2007


Yes, this is basically what I am doing. Only I use a "custom" class
for holding the result
(http://www.chemaxon.com/shared/pkovacs/concurrent/processors/ScheduledWorkUnitData.java)
instead of implementing the stock Future interface.

Thanks
Peter

On 4/4/07, Gregg Wonderly <gregg at cytetech.com> wrote:
>
>
> Peter Kovacs wrote:
> > The producers take their input from a file. They do a significant
> > amount of processing (build a model of a chemical compound from a
> > string representation into a Java objects, process the Java objects
> > and calculate a number of chemical properties of the molecule).
> > Producing the input for the consumer typically takes at least 30-35%
> > longer (but often much longer) than the consumer takes processing it.
> >
> > Admittedly, the room for concurrency is not huge, but is still
> > significant in two-way systems.
>
> Should you enqueue a Future for the object into the queue, and then let the
> consumer 'get' the value from there so that it is waiting for exactly the next
> value only?
>
> Gregg Wonderly
>


More information about the Concurrency-interest mailing list