Fix signal fences

[szegedi]

Fixes signal fences to consistently have acquire after load and release before store.

[github-actions]

Overall package size

Self size: 1.58 MB
Deduped: 1.95 MB
No deduping: 1.95 MB

Dependency sizes

| name | version | self size | total size | |------|---------|-----------|------------| | source-map | 0.7.4 | 226 kB | 226 kB | | pprof-format | 2.1.0 | 111.69 kB | 111.69 kB | | p-limit | 3.1.0 | 7.75 kB | 13.78 kB | | delay | 5.0.0 | 11.17 kB | 11.17 kB | | node-gyp-build | 3.9.0 | 8.81 kB | 8.81 kB |

_{🤖 This report was automatically generated by heaviest-objects-in-the-universe}

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-06-10 13:03:43

Comparing candidate commit c0cf28a in PR branch szegedi/fix-fencing with baseline commit 2f6f2f8 in branch main.

Found 3 performance improvements and 0 performance regressions! Performance is the same for 91 metrics, 26 unstable metrics.

scenario:profiler-light-load-no-wall-profiler-22

• 🟩 cpu_user_time [-8.681ms; -3.639ms] or [-11.520%; -4.828%]

scenario:profiler-light-load-no-wall-profiler-24

• 🟩 cpu_user_time [-9.933ms; -2.673ms] or [-12.459%; -3.353%]

scenario:profiler-light-load-with-wall-profiler-22

• 🟩 cpu_user_time [-6.794ms; -1.889ms] or [-6.026%; -1.676%]

[nsavoire]

This makes me wonder what prevents compiler from reordering gAsyncId = -1 before gcCount.store(newCount, std::memory_order_relaxed); ?
In the previous code, I believe std::atomic_signal_fence(std::memory_order_release); was preventing it.
This questions again my whole understanding of atomic_signal_fence...