[concurrency-interest] Fwd: ThreadPoolTask

Peter Veentjer alarmnummer at gmail.com
Mon Jul 10 03:10:30 EDT 2006


On 7/10/06, David Holmes <dcholmes at optusnet.com.au> wrote:
> Peter,
>
> Then it seems to me that what you are doing is going to extreme lengths to
> avoid creating a task instance per page.
I don't think I'm going to extreme lenghts. Creating a task instance
per page and resubmitting it I find more unnatural than using a
repeater. I'm still learning (a lot) about concurrency control and I
need structure that make it clear what I'm doing (concurrency control
is complex enough)  The Repeater gives me an bstraction that feels
natural for certain tasks.

And essentialy, a repeater or an executor with a copy queue is the
same. The copyqueue can be seen as an 'awaitablereference' because it
blocks if no value is available. And it sends back the same value if
one is available. So there is not much difference between the two
approaches.

I just needs something that feels more natural and gives me some
control on stuff I don't have with executors (like being
strict/nonstrict with concurrent tasks).

And I'm not a concurrency guru, I just love to work and think about
it. And that is why I need abstractions that feel natural.

Most "classic" executor usage in
> producer consumer problems involves executing the same task logic all the
> time - what changes is the data that the task operates on. You can easily
> reuse tasks instances if this generates too much garbage - afterall you only
> need as many task instances as there are worker threads.


>
> At the moment, based on what I'm reading, the repeater seems to be a
> solution to a problem of your own creation.
>
> Sorry if I'm still missing some issues here - lack of context always clouds
> such discussions. The discussions are enjoyable though. :)
>
> Cheers,
> David
>
> > -----Original Message-----
> > From: Peter Veentjer [mailto:alarmnummer at gmail.com]
> > Sent: Monday, 10 July 2006 4:41 PM
> > To: dholmes at ieee.org
> > Subject: Re: [concurrency-interest] Fwd: ThreadPoolTask
> >
> >
> > The parseSingleMessage looks like this:
> >
> > void parseSingleMessage(){
> >     Page page = pageInputChannel.take();
> >     try{
> >          ParsedPage parsedPage = parse(page);
> >          successOutputChannel.put(parsedPage);
> >     }catch(ParseException ex){
> >           errorOutputChannel.put(...);
> >     }
> > }
> >
> > The parser doesn't do any looping itself.
> >
> > This makes it very easy to test such components.
> >
> > > So if I'm understanding this right, what you have done is to invert the
> > > classic producer consumer loop so that instead of having a
> > consumer thread
> > > doing:
> > >
> > >    while ((parseTask = channel.take()) != STOP_TASK) { // just
> > an example
> > >        executeor.execute(new ParsingTask(parseTask));
> > >    }
> > >
> > > Your "executor" instead has worker threads that executes the same task
> > > instance that has a blocking run() method of the form:
> > >
> > >    while ((parseTask = channel.take()) != STOP_TASK) { // just
> > an example
> > >        parse(parseTask);
> > >    }
> > >
> > > Is that right?
> > >
> > > Cheers,
> > > David
> > >
> > >
>
>


More information about the Concurrency-interest mailing list