| 152 |
|
* node of a bin list itself as a lock, using plain "synchronized" |
| 153 |
|
* locks. These save space and we can live with block-structured |
| 154 |
|
* lock/unlock operations. Using the first node of a list as a |
| 155 |
< |
* lock does not by itself suffice though: When a node is locked, |
| 155 |
> |
* lock does not by itself suffice though. When a node is locked, |
| 156 |
|
* any update must first validate that it is still the first node, |
| 157 |
|
* and retry if not. Because new nodes are always appended to |
| 158 |
|
* lists, once a node is first in a bin, it remains first until |
| 291 |
|
* special, and do not contain user keys or values. Otherwise, |
| 292 |
|
* keys are never null, and null val fields indicate that a node |
| 293 |
|
* is in the process of being deleted or created. For purposes of |
| 294 |
< |
* read-only, access, a key may be read before a val, but can only |
| 294 |
> |
* read-only access, a key may be read before a val, but can only |
| 295 |
|
* be used after checking val. (For an update operation, when a |
| 296 |
|
* lock is held on a node, order doesn't matter.) |
| 297 |
|
*/ |
| 771 |
|
* valid. |
| 772 |
|
* |
| 773 |
|
* Internal traversals directly access these fields, as in: |
| 774 |
< |
* {@code while (it.next != null) { process(nextKey); it.advance(); }} |
| 774 |
> |
* {@code while (it.next != null) { process(it.nextKey); it.advance(); }} |
| 775 |
|
* |
| 776 |
|
* Exported iterators (subclasses of ViewIterator) extract key, |
| 777 |
|
* value, or key-value pairs as return values of Iterator.next(), |
