Repair Lazy Initialization Races

The problem

Race conditions during lazy initialization lead to duplicate client creation, thundering herds, or callers observing partially initialized objects. Standard 'if null' checks fail under concurrency, causing intermittent production crashes or leaked resources.

What it does

• Identifies unsafe double-checked locking and async memoization patterns in repository code.
• Reconstructs concurrent first-use timelines to pinpoint publication and visibility gaps.
• Implements canonical state machines (Empty, Initializing, Ready, Failed) for shared resources.
• Standardizes failure handling, retry logic, and shutdown coordination for singletons and caches.
• Generates deterministic concurrency tests with barriers to verify initialization safety.

Why this beats prompting it yourself

Most LLMs suggest basic locks that cause deadlocks or ignore memory visibility issues. This skill enforces a strict lifecycle for publication safety, ensuring that one initializer owns construction while others await a fully built value, including proper handling of poisoned promises.

Use cases

• Fixing duplicate database or SDK client instantiation during app startup.
• Repairing async initializers that memoize failed tasks permanently.
• Preventing crashes where callers access fields before a singleton is fully published.
• Coordinating resource disposal with active initialization to prevent use-after-free errors.

Known limitations

Local tests cannot enumerate every possible runtime schedule or hardware-specific memory model. The skill does not invent thread-safety guarantees for third-party libraries lacking them.