Fix shared_mutex reader starvation in MediapipeFactory::create()

[atobiszei]

MediapipeFactory::create() held a shared_lock on definitionsMtx for the entire duration of definition.create(), which in the graph queue path blocks on getIdleStream() waiting for a pool slot. With multiple inference threads continuously holding shared_locks, writers (createDefinition/reloadDefinition) needing unique_lock were starved indefinitely.

Fix: unlock definitionsMtx before calling definition.create(), since the map lookup is already complete and the definition object is kept alive independently.

Issue was detected by observing long execution times of our stress tests.

JIRA:CVS-193242

[Copilot]

Pull request overview

Updates MediapipeFactory::create() to prevent writer starvation by releasing the shared mutex before potentially blocking graph creation.

Changes:

• Unlocks definitionsMtx before calling definition.create().
• Allows definition reload writers to acquire the mutex promptly.

Suppressed comments (1)

src/mediapipe_internal/mediapipefactory.cpp:145

• This synchronization fix needs a regression test for the actual starvation interleaving: exhaust a graph queue so create() blocks in getIdleStream(), then invoke createDefinition or reloadDefinition on another thread and assert the writer completes before a queue slot is returned. The existing create/reload tests exercise these operations sequentially, so they would not catch a future reintroduction of the lock being held across the blocking call.

    // Unlock before create() which may block on graph queue, avoiding writer starvation.
    lock.unlock();

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.