[2.7] smaller lock in produce item

[pcnudde]

Fixes # .

Description

A few sentences describing the changes proposed in this pull request.

Types of changes

• Non-breaking change (fix or new feature that would not break existing functionality).
• Breaking change (fix or new feature that would cause existing functionality to change).
• New tests added to cover the changes.
• Quick tests passed locally by running ./runtest.sh.
• In-line docstrings updated.
• Documentation updated.

[pcnudde]

/build

[greptile-apps]

Greptile Overview

Greptile Summary

This PR optimizes the _get_item method in CacheableObject by moving the expensive produce_item() call outside the lock, significantly reducing lock contention when multiple receivers concurrently request the same item.

Key changes:

• Early cache availability check and immediate lock release (lines 91-100)
• produce_item() now executes without holding the lock (line 109)
• Double-checked locking pattern on re-acquisition: if another thread cached the item concurrently, use that result instead (lines 111-119)
• Preserves the reference count correctly when storing newly produced items (line 115)

The refactoring maintains correctness:

• Handles cache cleared scenario by returning produced item directly (lines 99-100)
• Prevents duplicate work when concurrent threads produce the same item
• Properly preserves the count field in cache tuples

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The refactoring implements a well-known double-checked locking pattern correctly. All edge cases are handled: cache invalidation (lines 99-100, 112), concurrent production (lines 113-119), and count preservation (line 115). The change is covered by existing comprehensive tests in cacheable_test.py which validate caching behavior, concurrent access, and cache clearing scenarios.
• No files require special attention

Important Files Changed

Filename	Overview
nvflare/fuel/f3/streaming/cacheable.py	Refactored _get_item to produce items outside lock, reducing contention when multiple receivers request same item concurrently. Uses double-checked locking pattern with proper cache invalidation handling.

Sequence Diagram

sequenceDiagram
    participant R1 as Receiver 1
    participant R2 as Receiver 2
    participant CO as CacheableObject
    participant Lock as Lock
    participant Cache as Cache

    R1->>CO: _get_item(0)
    CO->>Lock: acquire
    Lock-->>CO: acquired
    CO->>Cache: check cache[0]
    Cache-->>CO: (None, 0)
    CO->>Lock: release
    
    R2->>CO: _get_item(0)
    CO->>Lock: acquire
    Lock-->>CO: acquired
    CO->>Cache: check cache[0]
    Cache-->>CO: (None, 0)
    CO->>Lock: release
    
    Note over R1,R2: Both produce concurrently (lock-free)
    R1->>CO: produce_item(0)
    CO-->>R1: data_A
    R2->>CO: produce_item(0)
    CO-->>R2: data_B
    
    R1->>CO: re-acquire lock
    CO->>Lock: acquire
    Lock-->>CO: acquired
    CO->>Cache: check existing
    Cache-->>CO: None
    CO->>Cache: store (data_A, 0)
    CO->>Lock: release
    
    R2->>CO: re-acquire lock
    CO->>Lock: acquire
    Lock-->>CO: acquired
    CO->>Cache: check existing
    Cache-->>CO: data_A (from R1)
    Note over CO,R2: Discard data_B, use data_A
    CO->>Lock: release
    CO-->>R2: data_A

Loading

_{Last reviewed commit: 9471cfa}

[greptile-apps]

_{1 file reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[pcnudde]

/build

[greptile-apps]

_{1 file reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}