Question about ThreadPoolExecutor.execute implementation

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about ThreadPoolExecutor.execute implementation

Peter Veentjer - Anchor Men

I have a question about the implementation of the execute method of the
ThreadPoolExecutor. The code:

  public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();
        for (;;) {
            if (runState != RUNNING) {
                reject(command);
                return;
            }
            if (poolSize < corePoolSize &&
addIfUnderCorePoolSize(command))
                return;
            if (workQueue.offer(command))
                return;
            Runnable r = addIfUnderMaximumPoolSize(command);
            if (r == command)
                return;
            if (r == null) {
                reject(command);
                return;
            }
            // else retry
        }
    }

If the workqueue is full, and it stays full for a while because the
tasks take a long time to execute, doesn`t this call keep the cpu busy
with a busy wait? I don`t see any calls that let the thread wait untill
there is place.


Met vriendelijke groet,

Peter Veentjer
Anchor Men Interactive Solutions - duidelijk in zakelijke
internetoplossingen

Praediniussingel 41
9711 AE Groningen

T: 050-3115222
F: 050-5891696
E: [hidden email]
I : www.anchormen.nl

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Question about ThreadPoolExecutor.execute implementation

Moran Avigdor
If your BlockingQueue is defined with a fixed capacity, then
workQueue.offer(command) will return false when the queue is full,
and will resolve to adding a thread if we are still under the maximum
thread pool size. No busy wait, since a new thread will take the task.
Otherwise (reached max pool size), a rejection policy will be invoked.

If your BlockingQueue is defined without a fixed capacity, or
equivalent to
Integer.MAX_VALUE, then tasks will be queued up until
a thread becomes free to handle them.

Hope this helps.
Moran


Peter Veentjer - Anchor Men wrote:
I have a question about the implementation of the execute method of the
ThreadPoolExecutor. The code:

  public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();
        for (;;) {
            if (runState != RUNNING) {
                reject(command);
                return;
            }
            if (poolSize < corePoolSize &&
addIfUnderCorePoolSize(command))
                return;
            if (workQueue.offer(command))
                return;
            Runnable r = addIfUnderMaximumPoolSize(command);
            if (r == command)
                return;
            if (r == null) {
                reject(command);
                return;
            }
            // else retry
        }
    }

If the workqueue is full, and it stays full for a while because the
tasks take a long time to execute, doesn`t this call keep the cpu busy
with a busy wait? I don`t see any calls that let the thread wait untill
there is place.


Met vriendelijke groet,

Peter Veentjer
Anchor Men Interactive Solutions - duidelijk in zakelijke
internetoplossingen

Praediniussingel 41
9711 AE Groningen

T: 050-3115222
F: 050-5891696
E: [hidden email]
I : www.anchormen.nl

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


  

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: Question about ThreadPoolExecutor.execute implementation

Peter Veentjer - Anchor Men
In reply to this post by Peter Veentjer - Anchor Men
I have studied the addIfUnderMaximumPoolSize method and understand this call doesn`t get into a busy wait. The loop if for increasing the pool size to the maximum pool size and some point the pool is completely filled and or the task gets executed or is rejected.


Van: Moran Avigdor [mailto:[hidden email]]
Verzonden: woensdag 7 december 2005 11:06
Aan: Peter Veentjer - Anchor Men
CC: [hidden email]
Onderwerp: Re: [concurrency-interest] Question about ThreadPoolExecutor.execute implementation

If your BlockingQueue is defined with a fixed capacity, then
workQueue.offer(command) will return false when the queue is full,
and will resolve to adding a thread if we are still under the maximum
thread pool size. No busy wait, since a new thread will take the task.
Otherwise (reached max pool size), a rejection policy will be invoked.

If your BlockingQueue is defined without a fixed capacity, or
equivalent to
Integer.MAX_VALUE, then tasks will be queued up until
a thread becomes free to handle them.

Hope this helps.
Moran


Peter Veentjer - Anchor Men wrote:
I have a question about the implementation of the execute method of the
ThreadPoolExecutor. The code:

  public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();
        for (;;) {
            if (runState != RUNNING) {
                reject(command);
                return;
            }
            if (poolSize < corePoolSize &&
addIfUnderCorePoolSize(command))
                return;
            if (workQueue.offer(command))
                return;
            Runnable r = addIfUnderMaximumPoolSize(command);
            if (r == command)
                return;
            if (r == null) {
                reject(command);
                return;
            }
            // else retry
        }
    }

If the workqueue is full, and it stays full for a while because the
tasks take a long time to execute, doesn`t this call keep the cpu busy
with a busy wait? I don`t see any calls that let the thread wait untill
there is place.


Met vriendelijke groet,

Peter Veentjer
Anchor Men Interactive Solutions - duidelijk in zakelijke
internetoplossingen

Praediniussingel 41
9711 AE Groningen

T: 050-3115222
F: 050-5891696
E: [hidden email]
I : www.anchormen.nl

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


  

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest