| 169 |
|
* with a given probability per traversal step. |
| 170 |
|
* |
| 171 |
|
* In any strategy along these lines, because CASes updating |
| 172 |
< |
* fields may fail, the actual slack may exceed targeted |
| 173 |
< |
* slack. However, they may be retried at any time to maintain |
| 174 |
< |
* targets. Even when using very small slack values, this |
| 175 |
< |
* approach works well for dual queues because it allows all |
| 176 |
< |
* operations up to the point of matching or appending an item |
| 177 |
< |
* (hence potentially allowing progress by another thread) to be |
| 178 |
< |
* read-only, thus not introducing any further contention. As |
| 179 |
< |
* described below, we implement this by performing slack |
| 180 |
< |
* maintenance retries only after these points. |
| 172 |
> |
* fields may fail, the actual slack may exceed targeted slack. |
| 173 |
> |
* However, they may be retried at any time to maintain targets. |
| 174 |
> |
* Even when using very small slack values, this approach works |
| 175 |
> |
* well for dual queues because it allows all operations up to the |
| 176 |
> |
* point of matching or appending an item (hence potentially |
| 177 |
> |
* allowing progress by another thread) to be read-only, thus not |
| 178 |
> |
* introducing any further contention. As described below, we |
| 179 |
> |
* implement this by performing slack maintenance retries only |
| 180 |
> |
* after these points. |
| 181 |
|
* |
| 182 |
|
* As an accompaniment to such techniques, traversal overhead can |
| 183 |
|
* be further reduced without increasing contention of head |
