Commit 4b0a1cc
authored
fix: improve atomic ordering in ThreadPool and NAPI init (#310)
## Motivation
`ThreadPool` worker hot loops use `.acquire` on `err_flag.load()` where
`.monotonic` suffices — the flag is a pure early-exit signal with no
data dependency on the setter's other writes. BLS verification is
CPU-intensive, so relaxing this in the inner loop avoids unnecessary
memory-fence cost. Matches the pattern already used in
`src/state_transition/cache/pubkey_cache.zig`.
The earlier NAPI init-mutex changes from this branch have been dropped
after merging main, because main moved to zapi-managed lifecycle
(`js.exportModule` with `init`/`cleanup` hooks). The concurrent-register
race they were guarding against has been filed against zapi upstream:
ChainSafe/zapi#31.
## Description
`src/bls/ThreadPool.zig`:
- `err_flag.load(.acquire)` → `.monotonic` in `VerifyMultiWorkItem.exec`
and `AggVerifyWorkItem.exec` worker loops.
- Setter side (`err_flag.store(true, .release)` on pairing failure) is
unchanged — release semantics on the producer side carry no obligation
on the consumer to also be `.acquire` when the consumer doesn't depend
on the producer's other writes.1 parent bdf5b67 commit 4b0a1cc
1 file changed
Lines changed: 2 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
203 | 203 | | |
204 | 204 | | |
205 | 205 | | |
206 | | - | |
207 | 206 | | |
208 | 207 | | |
209 | 208 | | |
| |||
213 | 212 | | |
214 | 213 | | |
215 | 214 | | |
216 | | - | |
| 215 | + | |
217 | 216 | | |
218 | 217 | | |
219 | 218 | | |
| |||
347 | 346 | | |
348 | 347 | | |
349 | 348 | | |
350 | | - | |
| 349 | + | |
351 | 350 | | |
352 | 351 | | |
353 | 352 | | |
| |||
0 commit comments