Alternatives:

• Add a per-lru-instance state flag to allow reentrant or concurrent calls to be detected.
• Temporarily INCREF a link that is being used so that another thread or reentrant call can't destrory the link.
• Add a in-use flag to each link to preclude double updating or a free while in use.
• Go back to just the pure python version with its reentrant lock and more extensive and robust ref count logic. Keep the the make_key() step in C (while adding a field to make sure the hash only gets computed once).

Other ideas:

• Write a TLA+ spec for the lru_cache and use the model checker to identify the failing cases.

Here's a scenario that I'm worried about but haven't proved that it can occur.

• When a link is created, the lru_cache gets one reference but doesn't store it anywhere.
• When the link is added to the linked list, it is also added to the cache dict, giving a second reference.
• When a link is about to be evicted, it is first removed from the linked list.
• If a dict access triggers a reentrant or concurrent call into the lru_cache, that new code path can use the dict to find the link (already removed from the linked list but still in the dict) and try to move it to the front of the cache by updating the link fields. That puts it back into the linked list.
• The original code path resumes, believing that the link is removed from the linked list, and deletes the link from the dict, killing that last reference to the link.
• Now, the linked list has a list that is an orphan (no cache dict entry points at it) and that has a refcount of zero (deleted but still in memory, ready for reuse), and that will fail when it comes time to evict it. That will either segfault, overwrite something in use, drive the refcount negative, or silently corrupt the output.

Possible solutions (if in fact there is a problem):

• Don't use borrowed references in the links. Use actual references to establish the invariant: all links in the linked list have a ref count greater than zero, even if the links are orphans.
• Adopt the rotating root technique used in the pure Python code so that links don't get removed and readded with intervening dictionary calls. For a cache miss, the pure Python code leaves the links in place and only updates the key/result fields in the new link and invalidates those fields in the old link. In other words, it never leaves the links in an inconsistent state.

On general principle, I'd urge looking at ways that are "obviously correct" instead of "so clever I'm not sure whether I can concoct a failing case".

Two possibly relevant things follow from that. Whenever other threads or reentrancy may occur:

• Everything must be in a consistent state.

• Any reference that's borrowed when threading/reentrancy may begin must never be referenced again after threading/reentrancy returns. The easiest way to ensure this is to avoid borrowed references entirely.

Those are big steps on the way to "obviously correct". And obviously so, right? Don't fight sanity 😄.

https://bugs.python.org/issue35780 is closed. What is the status of this PR?