[concurrency-interest] ConcurrentHashMap in JDK7 code explanation (scanAndLockForPut)

罗傅聪 bayinamine at gmail.com
Fri Aug 8 04:15:01 EDT 2014


The source codes of the method scanAndLockForPut in ConcurrentHashMap in JDK7 says:

private HashEntry<K,V> scanAndLockForPut(K key, int hash, V value) {
    HashEntry<K,V> first = entryForHash(this, hash);
    HashEntry<K,V> e = first;
    HashEntry<K,V> node = null;
    int retries = -1; // negative while locating node
    while (!tryLock()) {
        HashEntry<K,V> f; // to recheck first below
        if (retries < 0) {
            if (e == null) {
                if (node == null) // speculatively create node
                    node = new HashEntry<K,V>(hash, key, value, null);
                retries = 0;
            }
            else if (key.equals(e.key))
                retries = 0;
            else
                e = e.next;
        }
        else if (++retries > MAX_SCAN_RETRIES) {
            lock();
            break;
        }
        else if ((retries & 1) == 0 &&
                 (f = entryForHash(this, hash)) != first) {
            e = first = f; // re-traverse if entry changed
            retries = -1;
        }
    }
    return node;
}
I understand what the codes mean, but what I don't is this else if entry:

else if ((retries & 1) == 0 && (f = entryForHash(this, hash)) != first)
My question is: Why do we have to do "(retries & 1) == 0"?

EDIT: I kind of figure it out. It's all because the constant MAX_SCAN_RETRIES:

static final int MAX_SCAN_RETRIES = Runtime.getRuntime().availableProcessors() > 1 ? 64 : 1;
In single core processor, MAX_SCAN_RETRIES = 1. So the second time the thread steps into the loop "while(tryLock)", it doesn't have to check whether the first node was changed.

However, in multi cores processor, this will behave like checking whether the first node is changed every 2 times in the while loop.

Is the above explanation correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140808/2621f19f/attachment.html>


More information about the Concurrency-interest mailing list