A
allen
Hi,
I have a question about Sun's implementation of
java.util.concurrent.ThreadPoolExecutor, specifically the execute(
Runnable ) method. The runState field is read before the Runnable task
is added to the workQueue (BlockingQueue), however there is no
synchronization in place. It seems that it might be possible for
another thread to invoke shutdown after runState is checked, but before
the task is added to the queue. Is it not then possible that the queue
is cleared by the shutdown process, the executor left as terminated,
only for the task to finally be added to the queue, something like:
Thread 1 | Thread 2
execute( t1 ) |
runState==RUNNING |
| shutdown
| runState=SHUTDOWN
| clear out workQueue
| return
| executor now terminated
|
workQueue.add(t1) |
return |
At this point, t1 is stuck in a queue that will never be cleared, but
no feedback to that effect was given on Thread 1.
Looking at Doug Lea's PooledExecutor at
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/PooledExecutor.java
I see that PooledExecutor.execute uses a synchronized block which would
prevent the above case from occuring.
Am I missing something?
cheers
Allen
I have a question about Sun's implementation of
java.util.concurrent.ThreadPoolExecutor, specifically the execute(
Runnable ) method. The runState field is read before the Runnable task
is added to the workQueue (BlockingQueue), however there is no
synchronization in place. It seems that it might be possible for
another thread to invoke shutdown after runState is checked, but before
the task is added to the queue. Is it not then possible that the queue
is cleared by the shutdown process, the executor left as terminated,
only for the task to finally be added to the queue, something like:
Thread 1 | Thread 2
execute( t1 ) |
runState==RUNNING |
| shutdown
| runState=SHUTDOWN
| clear out workQueue
| return
| executor now terminated
|
workQueue.add(t1) |
return |
At this point, t1 is stuck in a queue that will never be cleared, but
no feedback to that effect was given on Thread 1.
Looking at Doug Lea's PooledExecutor at
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/PooledExecutor.java
I see that PooledExecutor.execute uses a synchronized block which would
prevent the above case from occuring.
Am I missing something?
cheers
Allen