322 |
|
* situations in which we cannot guarantee to make node s |
323 |
|
* unreachable in this way: (1) If s is the trailing node of list |
324 |
|
* (i.e., with null next), then it is pinned as the target node |
325 |
< |
* for appends, so can only be removed later when other nodes are |
325 |
> |
* for appends, so can only be removed later after other nodes are |
326 |
|
* appended. (2) We cannot necessarily unlink s given a |
327 |
|
* predecessor node that is matched (including the case of being |
328 |
|
* cancelled): the predecessor may already be unspliced, in which |
344 |
|
* When these cases arise, rather than always retraversing the |
345 |
|
* entire list to find an actual predecessor to unlink (which |
346 |
|
* won't help for case (1) anyway), we record a conservative |
347 |
< |
* estimate of possible unsplice failures (in "sweepVotes"). We |
348 |
< |
* trigger a full sweep when the estimate exceeds a threshold |
349 |
< |
* indicating the maximum number of estimated removal failures to |
350 |
< |
* tolerate before sweeping through, unlinking cancelled nodes |
351 |
< |
* that were not unlinked upon initial removal. We perform sweeps |
352 |
< |
* by the thread hitting threshold (rather than background threads |
353 |
< |
* or by spreading work to other threads) because in the main |
354 |
< |
* contexts in which removal occurs, the caller is already |
355 |
< |
* timed-out, cancelled, or performing a potentially O(n) |
356 |
< |
* operation (i.e., remove(x)), none of which are time-critical |
357 |
< |
* enough to warrant the overhead that alternatives would impose |
358 |
< |
* on other threads. |
347 |
> |
* estimate of possible unsplice failures (in "sweepVotes"). |
348 |
> |
* We trigger a full sweep when the estimate exceeds a threshold |
349 |
> |
* ("SWEEP_THRESHOLD") indicating the maximum number of estimated |
350 |
> |
* removal failures to tolerate before sweeping through, unlinking |
351 |
> |
* cancelled nodes that were not unlinked upon initial removal. |
352 |
> |
* We perform sweeps by the thread hitting threshold (rather than |
353 |
> |
* background threads or by spreading work to other threads) |
354 |
> |
* because in the main contexts in which removal occurs, the |
355 |
> |
* caller is already timed-out, cancelled, or performing a |
356 |
> |
* potentially O(n) operation (e.g. remove(x)), none of which are |
357 |
> |
* time-critical enough to warrant the overhead that alternatives |
358 |
> |
* would impose on other threads. |
359 |
|
* |
360 |
|
* Because the sweepVotes estimate is conservative, and because |
361 |
|
* nodes become unlinked "naturally" as they fall off the head of |