Commit 4cfd4e5
Fix race condition in XNNPACK weights cache during concurrent
Summary:
D105123995 replaced the compile-time `#ifdef ENABLE_XNNPACK_WEIGHTS_CACHE` gate with a runtime `bool use_weight_cache` flag. However, the `weights_cache_mutex_` lock in `XNNPACKBackend::init()` only covered the `initialize_for_runtime()` call — the subsequent `compileModel()` (which calls `load_unpacked_data()`, `xnn_create_runtime_v4()`, and `finalize_for_runtime()`) ran unlocked against the shared `XNNWeightsCache`.
When two XNNPACK methods load concurrently (e.g., CRIA loading multiple ExecuTorch methods on separate IO threads), the second thread's `initialize_for_runtime()` resets `is_finalized_` to `false` and overwrites `named_data_map_` while the first thread is mid-`compileModel`. This causes:
- `delete_packed_data()` to fail with "cache is not finalized"
- `load_unpacked_data()` to fail because `named_data_map_` was overwritten
- `compileModel` to fail with error `0x24`
- Warmup/prefill to fail with ExecuTorch runtime error 36
The fix extends the lock scope to cover the entire init-compile-finalize sequence, matching the pattern already used by `execute()` and `destroy()`.
This diff was authored with Claude.
Differential Revision: D105753995init()
1 parent 3d86cc7 commit 4cfd4e5
1 file changed
Lines changed: 6 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
91 | 91 | | |
92 | 92 | | |
93 | 93 | | |
| 94 | + | |
| 95 | + | |
| 96 | + | |
| 97 | + | |
| 98 | + | |
94 | 99 | | |
95 | | - | |
| 100 | + | |
96 | 101 | | |
97 | 102 | | |
98 | 103 | | |
| |||
0 commit comments