| 32 |
|
* causes tasks to be immediately removed from the work queue at |
| 33 |
|
* time of cancellation. |
| 34 |
|
* |
| 35 |
+ |
* <p>Successive executions of a task scheduled via |
| 36 |
+ |
* <code>scheduleAtFixedRate</code> or |
| 37 |
+ |
* <code>scheduleWithFixedDelay</code> do not overlap. While different |
| 38 |
+ |
* executions may be performed by different threads, the effects of |
| 39 |
+ |
* prior executions <a |
| 40 |
+ |
* href="package-summary.html#MemoryVisibility"><i>happen-before</i></a> |
| 41 |
+ |
* those of subsequent ones. |
| 42 |
+ |
* |
| 43 |
|
* <p>While this class inherits from {@link ThreadPoolExecutor}, a few |
| 44 |
|
* of the inherited tuning methods are not useful for it. In |
| 45 |
< |
* particular, because it acts as a fixed-sized pool using |
| 46 |
< |
* {@code corePoolSize} threads and an unbounded queue, adjustments |
| 47 |
< |
* to {@code maximumPoolSize} have no useful effect. Additionally, it |
| 48 |
< |
* is almost never a good idea to set {@code corePoolSize} to zero or |
| 49 |
< |
* use {@code allowCoreThreadTimeOut} because this may leave the pool |
| 50 |
< |
* without threads to handle tasks once they become eligible to run. |
| 45 |
> |
* particular, because it acts as a fixed-sized pool using {@code |
| 46 |
> |
* corePoolSize} threads and an unbounded queue, adjustments to {@code |
| 47 |
> |
* maximumPoolSize} have no useful effect. Additionally, it is almost |
| 48 |
> |
* never a good idea to set {@code corePoolSize} to zero or use {@code |
| 49 |
> |
* allowCoreThreadTimeOut} because this may leave the pool without |
| 50 |
> |
* threads to handle tasks once they become eligible to run. |
| 51 |
|
* |
| 52 |
|
* <p><b>Extension notes:</b> This class overrides the |
| 53 |
|
* {@link ThreadPoolExecutor#execute execute} and |
