| 56 |
|
* considered individually, is not wait-free. One thief cannot |
| 57 |
|
* successfully continue until another in-progress one (or, if |
| 58 |
|
* previously empty, a push) completes. However, in the |
| 59 |
< |
* aggregate, we ensure at least probablistic non-blockingness. If |
| 59 |
> |
* aggregate, we ensure at least probabilistic non-blockingness. If |
| 60 |
|
* an attempted steal fails, a thief always chooses a different |
| 61 |
|
* random victim target to try next. So, in order for one thief to |
| 62 |
|
* progress, it suffices for any in-progress deq or new push on |
| 75 |
|
* push) require store order and CASes (in pop and deq) require |
| 76 |
|
* (volatile) CAS semantics. Since these combinations aren't |
| 77 |
|
* supported using ordinary volatiles, the only way to accomplish |
| 78 |
< |
* these effciently is to use direct Unsafe calls. (Using external |
| 78 |
> |
* these efficiently is to use direct Unsafe calls. (Using external |
| 79 |
|
* AtomicIntegers and AtomicReferenceArrays for the indices and |
| 80 |
|
* array is significantly slower because of memory locality and |
| 81 |
|
* indirection effects.) Further, performance on most platforms is |
