Runtime & concurrency
Reveal answer and reasoning
Define whether the cache owns resources, how consumers lease them, when keys may be removed, and what happens to failed or losing candidates. Keep raw GetOrAdd callbacks repeatable where possible. A retained Lazy or another single-owner wrapper can defer expensive initialization, but specify its execution mode, exception caching, and retry generations rather than calling it globally exactly once.
Use controlled callback gates to test competing construction, reuse, failure, removal, and cleanup without assuming a scheduler creates overlap. Ensure a losing candidate cannot dispose the winner or an active consumer's resource. The wrong design opens an irreversible external operation in every factory, ignores discarded values, and assumes one dictionary entry means one execution. For shared asynchronous work, cancellation ownership also needs a contract; one caller abandoning its wait should not automatically cancel the resource or task still owned by other consumers.
What a strong answer covers
- Specify cache, lease, removal, and cleanup ownership.
- Control competing construction in tests.
- Separate shared-operation cancellation from one caller's wait.
Common pitfall
Assuming a concurrent map automatically manages expensive resource lifetime and exactly-once effects.
Follow-up questions
- How would retries after cached failure be selected?
- How would you prevent disposal while consumers still use a value?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.