| 206 |
|
* As is too common in this sort of code, methods are monolithic |
| 207 |
|
* because most of the logic relies on reads of fields that are |
| 208 |
|
* maintained as local variables so can't be nicely factored -- |
| 209 |
< |
* mainly, here, bulky spin->yield->block/cancel code), and |
| 210 |
< |
* heavily dependent on intrinsics (VarHandles) to use inlined |
| 211 |
< |
* embedded CAS and related memory access operations (that tend |
| 212 |
< |
* not to be as readily inlined by dynamic compilers when they are |
| 213 |
< |
* hidden behind other methods that would more nicely name and |
| 214 |
< |
* encapsulate the intended effects). This includes the use of |
| 215 |
< |
* setRelease to clear fields of the per-thread Nodes between |
| 216 |
< |
* uses. Note that field Node.item is not declared as volatile |
| 217 |
< |
* even though it is read by releasing threads, because they only |
| 218 |
< |
* do so after CAS operations that must precede access, and all |
| 219 |
< |
* uses by the owning thread are otherwise acceptably ordered by |
| 220 |
< |
* other operations. (Because the actual points of atomicity are |
| 221 |
< |
* slot CASes, it would also be legal for the write to Node.match |
| 222 |
< |
* in a release to be weaker than a full volatile write. However, |
| 223 |
< |
* this is not done because it could allow further postponement of |
| 224 |
< |
* the write, delaying progress.) |
| 209 |
> |
* mainly, here, bulky spin->yield->block/cancel code. Note that |
| 210 |
> |
* field Node.item is not declared as volatile even though it is |
| 211 |
> |
* read by releasing threads, because they only do so after CAS |
| 212 |
> |
* operations that must precede access, and all uses by the owning |
| 213 |
> |
* thread are otherwise acceptably ordered by other operations. |
| 214 |
> |
* (Because the actual points of atomicity are slot CASes, it |
| 215 |
> |
* would also be legal for the write to Node.match in a release to |
| 216 |
> |
* be weaker than a full volatile write. However, this is not done |
| 217 |
> |
* because it could allow further postponement of the write, |
| 218 |
> |
* delaying progress.) |
| 219 |
|
*/ |
| 220 |
|
|
| 221 |
|
/** |
