Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Atomics APIを知る / Understanding Atomics API
Search
TOMIKAWA Sotaro
November 15, 2025
Programming
1
250
Atomics APIを知る / Understanding Atomics API
TOMIKAWA Sotaro
November 15, 2025
Tweet
Share
More Decks by TOMIKAWA Sotaro
See All by TOMIKAWA Sotaro
なんでRustの環境構築してないのにRust製のツールが動くの? / Why Do Rust-Based Tools Run Without a Rust Environment?
ssssota
15
49k
Web技術を最大限活用してRAW画像を現像する / Developing RAW Images on the Web
ssssota
2
2.4k
漸進。
ssssota
0
3.2k
Preact、HooksとSignalsの両立 / Preact: Harmonizing Hooks and Signals
ssssota
1
3.1k
useSyncExternalStoreを使いまくる
ssssota
6
6.2k
React CompilerとFine Grained Reactivityと宣言的UIのこれから / The next chapter of declarative UI
ssssota
8
5.6k
新しいAPI createRawSnippet触ってみた / What is the createRawSnippet?
ssssota
2
250
脱法Svelte / Evasion of svelte rules
ssssota
1
270
Documentation testsの恩恵 / Documentation testing benefits
ssssota
2
1.1k
Other Decks in Programming
See All in Programming
ハイパーメディア駆動アプリケーションとIslandアーキテクチャ: htmxによるWebアプリケーション開発と動的UIの局所的適用
nowaki28
0
330
「文字列→日付」の落とし穴 〜Ruby Date.parseの意外な挙動〜
sg4k0
0
360
connect-python: convenient protobuf RPC for Python
anuraaga
0
350
CloudNative Days Winter 2025: 一週間で作る低レイヤコンテナランタイム
ternbusty
7
1.9k
AIコードレビューがチームの"文脈"を 読めるようになるまで
marutaku
0
310
C-Shared Buildで突破するAI Agent バックテストの壁
po3rin
0
180
なあ兄弟、 余白の意味を考えてから UI実装してくれ!
ktcryomm
10
11k
開発に寄りそう自動テストの実現
goyoki
1
350
TypeScriptで設計する 堅牢さとUXを両立した非同期ワークフローの実現
moeka__c
6
2.9k
AI時代もSEOを頑張っている話
shirahama_x
0
230
AIコーディングエージェント(NotebookLM)
kondai24
0
120
React Native New Architecture 移行実践報告
taminif
1
130
Featured
See All Featured
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
1
78
Optimising Largest Contentful Paint
csswizardry
37
3.5k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Practical Orchestrator
shlominoach
190
11k
Agile that works and the tools we love
rasmusluckow
331
21k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
253
22k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
120
20k
Done Done
chrislema
186
16k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
How STYLIGHT went responsive
nonsquared
100
5.9k
Product Roadmaps are Hard
iamctodd
PRO
55
12k
Mobile First: as difficult as doing things right
swwweet
225
10k
Transcript
Atomics APIを知る sssssota / #jsconfjp
⾃⼰紹介 ssssota (冨川宗太郎) sは4つ / テックリード {x:"ssssotaro",gh:"ssssota"} フロカン北海道 → フロカン東京
→ Vue Fes 🔥 → JSConf JP
Atomics API 使ったことある⼈ 🙋
使ってみる Atomics.wait(new Int32Array(new SharedArrayBuffer(4)), 0, 0, 1_000); → https://stackblitz.com/edit/atomics-wait-sleep $
node --eval "Atomics.wait(...)" $ bun --eval "Atomics.wait(...)" $ deno eval "Atomics.wait(...)"
JavaScriptはシングルスレッドである JavaScript はプロトタイプベースで、マルチパラダイムで、シングルスレッドで、動的な言語 https://developer.mozilla.org/ja/docs/Web/JavaScript 計算、ユーザーのイベント、画面の描画が単一のスレッドで実行される。 簡潔さの一方で、重いタスクを実行すると画面がガタつく。 → Worker (Web Workers
/ Worker threads) でマルチスレッドに対応
Workers間の通信は? .postMessage() / .addEventListener('message') が使える。 基本的には、値はコピーされる。 addEventListener で値を受け取るので非同期での通信になる。 → 高速性のためのマルチスレッドで非同期通信&値コピーでよいのか?
メモリ空間を共有する マルチスレッドプログラミングでは、スレッド間の通信方法として2つに分られる。 • 共有メモリ • メッセージパッシング postMessage はメッセージパッシングに相当。 共有メモリを利用することで、 同期的かつコピーを伴わないスレッド間通信を実現する。
Agents(≒Workers)間で共有されたメモリ空間を操作するArrayBuffer ArrayBufferなので、DataView経由で読み書きする。 const sab = new SharedArrayBuffer(1024 /* bytes */);
const i32arr = new Int32Array(sab); // DataView i32arr[0] = 0xFF; SharedArrayBuffer
バイナリしか扱えない問題 ArrayBufferなので、数字しか格納できない。 ?「Workers間でデータをやり取りするのに文字列も送れないなんて😫」 → 自分で数値に変換してください。数値に変換しづらいものに使うべきではない。 最悪JSON.stringify + TextEncoderとか、 new TextEncoder().encode(JSON.stringify(obj))
typed-cstructというOSSもよいかも
競合‧同期問題 「特定のメモリを読んで、数値を足して、書き込む」ことを考える 2つのワーカーが +1 ずつすると合計は +2 になってほしい。 が、ならないこともある。 これを、Data race(データ競合)
という。 また、タスクが完了したことを 知るすべもない。
Atomics API 競合を回避するAtomicな操作、「不可分操作」を行うためのAPI Atomics.add() を使用して加算すれば、競合を回避しつつ加算・書き込みが可能。 Atomics.wait() / Atomics.notify() を使用すれば書き込みを通知できる。
Web WorkersはWeb API 2010年HTML5仕様 → HTML Living Standard 一方、SharedArrayBufferとAtomicsはECMAScript仕様に含まれる tc39/proposal-ecmascript-sharedmem
→ ES2017 Web Workersはブラウザでしか使用できない。 Node.js、Deno、Bunはそれぞれ独自のWorkers実装を持つ。 SharedArrayBufferとAtomicsはJavaScriptエンジンに実装されている。 仕様
SharedArrayBuffer is not defined おもむろに新しいタブでJavaScriptコンソールを開いて > new SharedArrayBuffer(4) してもエラーになる。 エンジンに実装されているなら、どこでも使えるんじゃ...?
2018年に発表されたSpectreという脆弱性により、 SharedArrayBufferは一時的に無効化された。 悪用することでプロセス外のメモリが読める。 現在は条件付きで利用できる。 条件を満たしていない環境では、SharedArrayBufferは利用できない。 条件は以下の2点: • 保護されたコンテキスト内である (window.isSecureContext) •
オリジン同士が分離されている (window.crossOriginIsolated) 無効化されたSharedArrayBuffer
SharedArrayBuffer / Atomics だれが使っている? Workersが必要なケースは少なくないが、SharedArrayBuffer, Atomicsは? → WebAssemblyをビルドするEmscriptenがマルチスレッド対応に利用 具体的には ffmpeg.wasmなど。
ただし、WASM側のAtomics操作を使うため、JSのAtomicsは使われていない。 Atomicsは本当に使われている?
Atomics.wait(new Int32Array(new SharedArrayBuffer(4)), 0, 0, 1_000); Atomics.waitはSABの値が変化するのを待機する。引数は以下: 1. typedArray: Int32Array
| Int64Array 2. index: number 3. value: number 4. timeout?: number → Int32Arrayのindex:0の値が0じゃなくなるまで最大1,000ミリ秒待機 Atomics.waitはブロッキング操作なのでメインスレッドでは使えない。 最初のサンプルの解説
⾼度な使⽤例: PartyTown Third-partyスクリプトの実行をWeb Workerに逃がしパフォーマンス向上を図る 1. Web Worker上で実行されるDOM操作等をProxyで補足 2. 補足した操作をMain threadに送信→Atomics.waitで完了を待つ
3. Main threadでDOM操作を実行、Atomics.notifyで完了通知 4. SharedArrayBuffer経由で返り値返却 制約はありつつも意欲的な解決策。 SharedArrayBufferが使用できない環境ではXHR+ServiceWorkerを利用。
おわり Atomics APIは SharedArrayBuffer とともに JavaScriptによる高速で安全な並列処理をもたらした。 JavaScriptのAtomicsはあまり使われていない(?) WebAssemblyからSharedArrayBufferを利用するケースが多いし、 使われていても、同期的な待機状態を作る目的だったりする。 あなたはAtomics
API どう使いますか?