[concurrency-interest] Problem in customizing the Executor framework behaviour
a.shahkar at ieee.org
Wed Jul 15 08:25:12 EDT 2009
Thanks Erkin. Your idea about supplying the delay to the task's
constructor solved one aspect of the problem. Delays are no more
considered a dark point. Nice idea!
> So you can create your ThreadPoolExecutor first then pause, submit all
> the tasks and unpause the the threadPoolExecutor. So when test starts,
> you will not observe any delay because of request production.
I think actually now you can really understand what I was talking about in my original post.
As I told before, total number of requests (N) can be a very large number. Submitting a few thousand tasks makes the executor create a huge list of identical items. Not only this approach is extremely inefficient, but it also does not allow the application to make N equal to infinity. What is wrong with a user code which wants the framework's library to keep sending requests in a few threads until shut down?
As you might remember, I told about a customized ArrayBlockingQueue given to the executor in my original post. I thought that such a construct could return one task for N times, solving the huge list problem. It can hold an internal parameter which is equal to N and decrement it each time a thread fetches a task to execute. Or it can ignore the parameter if total number of requests is not known. The problem is, I don't know really how I can effectively implement such a construct which does not harm performance. I don't know which methods should be overriden and in what way. This somehow requires a deep understanding of how an executor works with its BlockingQueue.
Can you help me to implement the customized ArrayBlockingQueue?
Again, thank you for your idea on solving the delays problem.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest