Rust part34

**デフォルトの名無しさん** · 2025/11/27(木) 12:25:23.76

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part33
https://mevius.5ch.net/test/read.cgi/tech/1755247770/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/12/06(土) 16:19:08.82

自作のソフトウェアのコードRustで書いてんだけどやっぱビルド周りが遅いな
cargo testも実行まで時間かかるし
もっと速くならんかな

**デフォルトの名無しさん** · 2025/12/06(土) 17:30:19.35

なんでcと速度は変わらんのにビルドこんな遅いん？

**デフォルトの名無しさん** · 2025/12/06(土) 17:43:56.21

Rustはメモリリーク含めたリスクポイントをコンパイル時点で教えてくれるだけ。
panicで止めるかどうかは、異常系分類による。
停止させると逆に危険な場合もあるので、自前のexceptアナライザーは必須。
とにかく、関心事の放散が防止できれば、メモリアロケーションもリリースもミスは少なくなる。
SOLID原則に従えば、エレベーターも止まらない。　Rustの出発点が変な気もする。
アーキテクチャー不在がエレベーターを止める。

**デフォルトの名無しさん** · 2025/12/06(土) 23:34:40.22

異常系という言葉を気軽に使う人間は絶対に信用してはいけない
重大障害のもと

**デフォルトの名無しさん** · 2025/12/07(日) 01:56:01.10

どういう理屈で？
当該用途にはなんて言葉を使えばいいの？

**デフォルトの名無しさん** · 2025/12/07(日) 02:51:57.24

半永久的に動き続けることが求められるサーバーでは異常系終了を用いない
それだけの話だろう

**デフォルトの名無しさん** · 2025/12/07(日) 03:31:02.57

イージーモード追加してくれんかな
trycatchとかgoみたいなエラー処理やりたい

**デフォルトの名無しさん** · 2025/12/07(日) 04:14:18.61

Goには例外try/throw/catchもなければResultのような代数的データ型もない
Goは多値でエラーを返してif文でそれがnilかどうかを判別するしかなくイージーモードとはかけ離れている

**デフォルトの名無しさん** · 2025/12/07(日) 04:23:57.95

>>72
システム開発における正常／異常系はテストケースの話じゃないの？
異常終了させないためには、なおのこと異常系は肝要なのでは

**デフォルトの名無しさん** · 2025/12/07(日) 05:47:16.97

unwrap()の是非について焼き寿司氏のblog
https://burntsushi.net/unwrap/

仮にリンターでunwrap()の有無をチェックしても
slice[i] や RefCell、場合によっては算術演算のラップアラウンドでもパニックするよ
という指摘にはなるほどと思った

**デフォルトの名無しさん** · 2025/12/07(日) 08:25:06.65

>>76
Linusの指摘そのままじゃない？
「ランタイムエラーでパニックを発生させるのは根本的に問題があると思っている」

OSみたいなクリティカルな用途だから要求も高いというのはあるけど、Rustはc用途を目指しているんだから、他人のコードであってもpanicを制御できるようにならなきゃ話にならんかと。

**デフォルトの名無しさん** · 2025/12/07(日) 09:49:00.07

>>77
std::panic::catch_unwind でキャッチする仕組みはある。
ただ C++ の例外と同じでランタイムサポートの支援で実現するものだから、それより下のレイヤ (OS など) を作ってるときには使いにくいんだよ。
結局のところ OS のレイヤでは C でやってるのと同じやり方でなんとかするしかない。

**デフォルトの名無しさん** · 2025/12/07(日) 11:31:53.26

unwrap()の是非について
https://www.youtube.com/watch?v=TalW9HN9_hI
流行って来た

**デフォルトの名無しさん** · 2025/12/07(日) 13:14:55.38

>>77
slice[i]やRefCellや算術演算で発生するpanicと
OOMをResultでハンドリングする機能がなく避けようがなかったpanicとは種類が違う

前者はプログラムコードのバグ
後者はプログラムコードにバグがなくても環境次第で発生してた

Linusが正確に何と言ったかは知らんけど
環境次第で実行時に発生するエラーを
panicとしてしか扱えなかったことを問題視したんじゃないか？

**デフォルトの名無しさん** · 2025/12/07(日) 13:17:17.08

>>79
複おじに毛が生えたレベルの説明だが
その毛があるかないかの違いが重要なのかもな

**デフォルトの名無しさん** · 2025/12/08(月) 06:14:53.89

iced 0.14.0がリリースされて、ついに日本語入力に対応したらしいよ

> Input method support. #2777

**デフォルトの名無しさん** · 2025/12/08(月) 10:36:18.01

驚き！

**デフォルトの名無しさん** · 2025/12/08(月) 17:44:28.10

なにicedって

**デフォルトの名無しさん** · 2025/12/08(月) 19:41:58.70

UIライブラリや

**デフォルトの名無しさん** · 2025/12/09(火) 13:17:43.50

rustでUIやる意味何？計算量の多いゲームエンジンならわかるけどただのアプリならコンパイルの遅いrustでなんか作りたくねえ

**デフォルトの名無しさん** · 2025/12/09(火) 13:24:51.74

make world と打ち込んで1週間待ってた頃に比べれば全然余裕

**デフォルトの名無しさん** · 2025/12/09(火) 13:28:09.51

Borlandがturbo rustを出すまで我慢だね

**デフォルトの名無しさん** · 2025/12/09(火) 13:31:43.36

turbo visionのcrateはあるんだw

**デフォルトの名無しさん** · 2025/12/09(火) 13:34:26.68

でもgpuiつかったやつめちゃ速くない？
あとrust analyzerのメモリ爆食いどうにかしてクレメンス

**デフォルトの名無しさん** · 2025/12/09(火) 18:55:52.01

実際C++BuilderのGUI生産性と、Rustの言語としての速さと頑強さが組み合わされば無敵じゃね？

**デフォルトの名無しさん** · 2025/12/09(火) 20:27:29.76

まあエンバカデロはもう革新的な製品作りそうにないし
ヘジルスバーグはRustにあまり興味なさそうだけどね

**デフォルトの名無しさん** · 2025/12/10(水) 05:02:49.84

Gemini君に聞いたら、RustはC++のNRVOに相当する最適化をC++よりも広い適用範囲で強力に行います
Destination Passing Style (DPS)
って事らしいけど本当かな？

**デフォルトの名無しさん** · 2025/12/10(水) 09:50:22.74

C++ はオブジェクトへのアクセスが自由過ぎてエイリアス解析が大変 (最適化がしんどい) というのは昔から言われてた。
逆に言えば参照 (オブジェクトの依存関係) を完璧に追える Rust ではもっと上手くやれてもおかしくはないと思う。

**デフォルトの名無しさん** · 2025/12/10(水) 10:28:50.81

面倒くさい奴だけど付き合うと意外と良い奴

**デフォルトの名無しさん** · 2025/12/10(水) 11:00:48.64

>>93
Rustの方針はシンプルかつ効率
関数がレジスタ返しできない大きなサイズのデータを返す時
呼び出し側の関数のスタックフレームに領域を確保
呼び出された関数は最初からその領域にデータを書き込む
もちろんこれらは裏で自動的に行われる

**デフォルトの名無しさん** · 2025/12/10(水) 11:29:15.14

日本語不自由なやつしかおらんのかいな

**デフォルトの名無しさん** · 2025/12/10(水) 11:31:30.40

"Destination Passing Style" で検索するとHaskellの話しか出てこないからハルシネーションか？

**デフォルトの名無しさん** · 2025/12/10(水) 11:32:51.92

RustはUIでも覇権取れる？

**デフォルトの名無しさん** · 2025/12/10(水) 11:48:09.95

はい

**デフォルトの名無しさん** · 2025/12/10(水) 12:06:24.08

C++でもまじめにstd::move()通してればRust並に最適化できるんじゃね？
move後のアクセスをコンパイラが止めないからミスった時に何が起こるか分からんけど

**デフォルトの名無しさん** · 2025/12/10(水) 12:18:26.32

equi

**デフォルトの名無しさん** · 2025/12/10(水) 12:28:49.76

>>101
C++ では返却値は std::move しないのが望ましい場合が多い。
コピー省略できるはずのところでムーブになってしまうことがあるし、ムーブが妥当なときはなにも書いていなくても暗黙にムーブするので書く意味がない。

**デフォルトの名無しさん** · 2025/12/10(水) 12:31:05.43

Rustは概念的には常に自動的にmoveされる
そして生成コードはレジスタ返しか足りなければRVOに自動的になる
だからC++のような複雑さも面倒臭さもない

**デフォルトの名無しさん** · 2025/12/10(水) 12:44:35.63

moveが暗黙で実際どうなんかがわからんのはC++の辛いところ
std::moveって明記してるのにコピーした時は、コンパイルエラーにしてくれてればよかったのに

**デフォルトの名無しさん** · 2025/12/10(水) 12:47:17.53

>>104
現在のC++が自動でRVOになるのは仕様で保証されてるけど
RustのRVOは仕様じゃなく現状そうなることが多い程度の話では？

**デフォルトの名無しさん** · 2025/12/10(水) 12:58:04.34

>>106
むしろRVO以外でどうやって大きなデータを返すんだよ
勝手に裏でヒープでも使うのか？
RVOにならない例を示してみろよ

**デフォルトの名無しさん** · 2025/12/10(水) 13:16:30.40

Rustはできるだけインライン展開してreturn自体を減らしてそう
C++とはコンパイルの単位とプロセスが違うからRVOは重視してないかもしれない

**デフォルトの名無しさん** · 2025/12/10(水) 13:57:35.08

>>107
んな大袈裟な話じゃないし、ボトルネックになってない限り実際にRVOされてるかどうかまで気にする人は少ない
コピーのコストが大きな問題になるようなクソでかい構造体なんて実際問題として滅多にないからね
コンテナは基本的に中でヒープ使ってるってのはさすがに知ってるよな？

**デフォルトの名無しさん** · 2025/12/10(水) 16:52:00.70

non-goalの余白に無限の願望を託す人

**デフォルトの名無しさん** · 2025/12/10(水) 17:49:43.54

>>109
関数からデータを返すだけでヒープを使うのは愚かなことだ
もちろんRustでは戻り型がBox<T>等でなくTそのものならヒープが使われることはないので問題は起きないが

**デフォルトの名無しさん** · 2025/12/10(水) 19:32:55.35

なんでRustはReactに勝てないのか分からんのやが誰か教えてくれ

**デフォルトの名無しさん** · 2025/12/10(水) 19:56:08.60

web apiてなんであんなうんこスクリプト言語で書くってことになったんだろう
js自体の機能てほぼないしweb apiいじってるだけだからcでもいいやん

**デフォルトの名無しさん** · 2025/12/10(水) 19:59:11.30

rustでは値渡しはクローンしなければムーブになるだろうな

**デフォルトの名無しさん** · 2025/12/10(水) 20:34:20.54

>>114
C++のmoveはコピーコンストラクタの呼び出しを回避するのが目的である一方、
Rustの値渡しは(最適化を無視すれば)常に単なるビット毎のシャローコピーであり、RustにC++のmoveに相当するものは存在しない
Rustのmoveは所有権の移動という文脈上の仮想的な操作でしかなく、代入の実行時挙動は一切変化しない点でC++のmoveとは全く異なる概念

**デフォルトの名無しさん** · 2025/12/10(水) 20:37:02.84

JavaScriptへトランスパイルできる言語はいくつかある
TypeScriptは言わずもがなDartとKotlinも公式で保守されてる
JavaScriptを書くために必ずしもJavaScriptを使う必要は無い

**デフォルトの名無しさん** · 2025/12/10(水) 20:41:05.28

>>113

**デフォルトの名無しさん** · 2025/12/10(水) 23:42:16.04

>>112
Webブラウザで動くフレームワークとプログラミング言語を比較するのはヤバい

>>113
JavaScriptは大量のイベントが発生してそれらが非同期に並行して動くけどシングルスレッドだから排他制御は要らないというのが楽に書けるよう設計されてる
Cには無理がある

**デフォルトの名無しさん** · 2025/12/11(木) 00:22:02.01

>シングルスレッドだから排他制御は要らない
お前がそう思うんならそうなんだろうお前ん中ではな

**デフォルトの名無しさん** · 2025/12/11(木) 00:23:17.13

同時実行制御のことを雑に排他制御と呼ぶやつにプログラミングをさせてはいけない
排他制御も同時実行制御もどちらも絶対理解してないから

**デフォルトの名無しさん** · 2025/12/11(木) 08:30:48.24

>>120
誤解してないか？
こういう関係だぞ

https://en.wikipedia.org/wiki/Mutual_exclusion
In computer science, "mutual exclusion" (排他制御) is a property of "concurrency control" (同時実行制御), which is instituted for the purpose of preventing race conditions.

**デフォルトの名無しさん** · 2025/12/11(木) 10:34:14.13

RustのmoveもC++のmoveも、
「(仮に最適化されずとも)構造体のシャローコピーのコストは一般に軽く、多くの場合問題にならない」
というのが大前提なのだけど、>>107>>111は根本的なところを理解してなそう
RustやC++に限らず、GoやC#など構造体の値渡しができる言語に基本的に共通する大前提だね

**デフォルトの名無しさん** · 2025/12/11(木) 11:24:54.77

そういう問題ではない
呼び出し元関数のスタックフレームに直接書き込むのがRVO
配列もヒープを利用しない

**デフォルトの名無しさん** · 2025/12/11(木) 12:43:57.33

レジスタ渡しよりも高速
余分なコードが介在しないCよりも
余分なコードだらけのRustが速くなるとしたらその辺が原因かもな

**デフォルトの名無しさん** · 2025/12/11(木) 12:54:01.07

複オジだらけ

**デフォルトの名無しさん** · 2025/12/11(木) 12:58:56.52

自作自演

**デフォルトの名無しさん** · 2025/12/11(木) 18:48:54.72

>>124
返し値に利用可能なレジスタの範囲内ならレジスタ返しが速い
RVOはそのサイズを超えてから

**デフォルトの名無しさん** · 2025/12/11(木) 22:15:21.89

RVOとは違う話だけどC++は戻り値を std::move した方が良いケースは結構あるぞ
戻り値というか、戻り値の型に渡すコンストラクタに対して渡す時の話だけど
戻り値が std::string や std:: vector をフィールドに持つ構造体やタプルで、最後の return で初期化してるような場合

return { std::move(str); };

こういう場合は str は自動ではちゃんとムーブしてくれなかった気がする
(最近のC++は知らんから、間違ってたら指摘がほしい)

**デフォルトの名無しさん** · 2025/12/11(木) 22:42:19.12

みんな当たり前にC++を引き合いに出しているけど、Rust書いてる人でC++エアプ勢っていないんだろうか

**デフォルトの名無しさん** · 2025/12/11(木) 23:34:58.81

Cのみはいるかもしれないが、少なくともC系統の言語を触れてないと
Rustがこんなに苦労して解決しようとしてる問題への実感が持てなくて
GC言語やスクリプトよりちょっと速いだけの、冗長構文クソ言語以外に感想持てなそう

**デフォルトの名無しさん** · 2025/12/11(木) 23:46:18.77

>>121
何を誤解してると思ったの？

それとその定義だとconcurrency controlは常にmutual exclusionというpropertyを持ってるという関係になるけどCSの一般的定義ではそういう関係ではなくてconcurrency controlを実現する手段の一つとか実現手段の一部という関係

**デフォルトの名無しさん** · 2025/12/12(金) 00:36:09.89

横からだけど、引用文においてもミューテックスは並行プログラミングにおける安全性アプローチのひとつと定義してると思うが
両者共に「並行制御 ⊃ 排他制御」という認識ではないの？
何が論点になってんだ？

**デフォルトの名無しさん** · 2025/12/12(金) 01:29:09.26

>>132
ミューテックスが必要となるのは「並列」プログラミング
拡張ワーカーを使わない限り
JavaScriptは「並行」プログラミングかつシングルスレッドなのでミューテックスが不要

**デフォルトの名無しさん** · 2025/12/12(金) 02:06:45.48

>>128
最近のC++では間違い

std::move()を書かなくても自動でムーブしてくれるし、
わざわざstd::move()を書いたことでNRVOを妨害してしまう

**デフォルトの名無しさん** · 2025/12/12(金) 02:22:06.56

>>133
>JavaScriptは「並行」プログラミングかつシングルスレッドなのでミューテックスが不要

そこは JavaScript は並行プログラミング"でありながら"じゃね？
「ミューテックスの要否」は「シングルスレッドであること」で定まり、したがって「並行プログラミングであること」を接続詞"かつ"で「並行させる」のは説明として不適かと

そしてなんについて議論してんの？
おふたりが論点としているものがはたから見ていて判然とせん

**デフォルトの名無しさん** · 2025/12/12(金) 02:41:47.22

>>132が並列と並行の区別ができてないからでしょう

**デフォルトの名無しさん** · 2025/12/12(金) 03:11:39.93

>>136
それは具体的にどの部分からそう読み取ったの？

「シングルスレッドであること」によって、「ミューテックスの要否」は定まる
したがって並列か並行かとは別議論では？
そもそも本件において前者は考慮不要かと

**デフォルトの名無しさん** · 2025/12/12(金) 03:30:00.02

>>137
mutexは同じCPU内の話だから並列＝マルチスレッドでしょ
でも>>132は区別できてなくて並行プログラミングと書いてます
並行プログラミングでは値を同時に更新することがないためmutexは要らないです
並行並列プログラミングまたは並列プログラミングの時のみmutexが要ります

**デフォルトの名無しさん** · 2025/12/12(金) 06:22:33.05

>>138
>mutexは同じCPU内の話だから並列＝マルチスレッド

ミューテックスの要否は端的に言えば「共有リソースに対するアクセスの有無」
マルチスレッドは並列を実現するためのいち技術であり、限定するのはミスリード
マルチコア、マルチソケット（NUMAなど）もまたしかり
「同じCPU内」という単位は不正確

>でも>>132は区別できてなくて並行プログラミングと書いてます

「並行制御 ⊃ 排他制御」と同じこと
「並行 ⊃ 並列」で並行は抽象レベルの概念であり、並列は物理レベルの実現方法
前者が後者を含意するのでこれらの記述は極めて自然

>並行プログラミングでは値を同時に更新することがないためmutexは要らないです

したがってこれは明確に誤り
>>136 を熨斗付けてお返しいたします

>並行並列プログラミングまたは並列プログラミングの時のみmutexが要ります

同上
レイヤの違う概念、用語を並行させて書いてしまってる
重ねるけれど、ミューテックスの要否基準は「共有状態の同時アクセス可能性」のみ

とりあえず >>121 の引用部分がそもそも間違ってるという主張？
そうであるなら以下に対して反論どうぞ

>In computer science, mutual exclusion is a property of concurrency control, which is instituted for the purpose of preventing race conditions.

**デフォルトの名無しさん** · 2025/12/12(金) 06:46:29.30

>>139
あなたのような知識が足りなく偏った人を相手にするのは大変だけど
単に並列プログラミングといえば複数のPCを用いる分散型の並列プログラミングを含むのよ
話題の領域を明確にするために今回はmutexの話だから分散型の話題ではないと限定しているわけ
そういう常識を持たないかあえて無視して無意味に突くだけのダメ人間みたいだからこれ以上はくだらないやりとりしません

**デフォルトの名無しさん** · 2025/12/12(金) 08:00:06.77

>>140
>単に並列プログラミングといえば複数のPCを用いる分散型の並列プログラミングを含むのよ

いやあ、そんなことはないと思うが
少なくともこちらは本件において分散コンピューティングには触れていない

>今回はmutexの話だから分散型の話題ではないと限定しているわけ

心得てるけど
その上で「ミューテックスの要否」は「共有リソースに対する同時アクセスの有無」と言明しているわけであり

あなたが以下のようにミューテックスの用途を誤解、もしくはミスリードをしていたもので、反例をいくつか挙げてわざわざ説明したのであって（マルチコア、マルチCPU = マルチソケット｟同一マシン内のNUMAノード間｠）
マルチスレッドは並列の一形態でイコールではない
共有リソースへの同時アクセスが起こりうるなら、スレッド、コア、ソケットの別なく排他制御はごくごく自然な選択肢
ちなみにNUMAはわかる？複数PCの使用や分散技術の話じゃないよ

>mutexは同じCPU内の話だから並列＝マルチスレッドでしょ

そしてそもそも並列と並行の区別だが、これについてもレイヤが違うと説明したはず
「並行 ⊃ 並列」
並行はより上位の抽象概念だから、並行プログラミングに言及する際、ミューテックス（排他制御）を取り上げるのは当たり前

したがって以下は明確に誤ってるかと

>並行プログラミングでは値を同時に更新することがないためmutexは要らないです

並列だろうが並行だろうが、リソースへの競合状態が起こりえるなら、ミューテックスは要検討

**デフォルトの名無しさん** · 2025/12/12(金) 09:10:06.26

JavascriptのPromise chaining（シリアル実行）は排他制御に含まれると思う
前の処理がPendingの間は次の処理を実行しないから前の処理で更新中のデータが次の処理で参照されない

**デフォルトの名無しさん** · 2025/12/12(金) 10:18:13.52

>>139
間違い多すぎなので正解だけ書くと
並行処理＝同時進行するが同時に実行されることはない
並列処理＝同時に実行されるためメモリ競合などの対策が必要

**デフォルトの名無しさん** · 2025/12/12(金) 19:40:37.53

T型を[T;1]型にするのはゼロコストだよね

**デフォルトの名無しさん** · 2025/12/12(金) 21:31:17.66

>>143
>並行処理＝同時進行するが同時に実行されることはない
>並列処理＝同時に実行されるためメモリ競合などの対策が必要

教科書レベルのあるある理解（誤解）
既述したよう、並列処理は並行処理のいち手段
「並行」という概念の中に含まれる
それを物理レベルで「並列に処理」（同時実行）するか否かは別議論であり、レイヤが違う

並列でないなら競合しないの？
並列でないならマルチスレッド処理できない？

整理したいけど >>121 の引用部分に異議ある立場？

>In computer science, mutual exclusion is a property of concurrency control, which is instituted for the purpose of preventing race conditions.

「concurrent」をどう訳します？

**デフォルトの名無しさん** · 2025/12/12(金) 22:57:57.08

>>134
不安になって試してみたけど、このケースだと現代のC++コンパイラでも std::move が必要だぞ
>>128 の変数 str の部分を non-copyable なもの (例. std::unique_prt<T>) に変えると、std::move 無しだとコンパイルエラーになる
自作クラスで試しても、std::moveしないとコピーが作られる (外側の構造体そのものはRVO最適化が効くけど、その構造体に渡されるデータは左辺値参照で渡される)

**デフォルトの名無しさん** · 2025/12/12(金) 23:21:06.40

wikipediaを見る限り>>143の区別みたいよ

>並行計算は、並列計算（parallel computing）としばしば混同される。
>
>並列計算はマルチプロセッサ前提であり、独立した各プロセッサが割り振られた計算を同時実行することを指す。
>故にシングルプロセッサでは不可になる[2]。
>分散システム内の各コンピュータが割り振られた計算を同時実行するのもそうである。
>
>並行計算は一つのプロセッサに複数のタスクを存在させて、各タスクに計算を割り振ることを指す[4]。
>そこではタイムシェアリング技術などが使われる。

**デフォルトの名無しさん** · 2025/12/12(金) 23:23:20.57

>>132
AはBのproperty(特性/性質/属性)の一つという定義と
AはBを実現するアプローチの一つ定義は同じではないよ

これはどっちかが絶対的な正解という問題ではなくて
mutual exclusionをどういう意味範囲で使ってるかの問題

compare-and-swapのようなatomic operationでも
レイヤーを掘り下げればクリティカルセクションがあって
mutual exclusionというpropertyを持ってると考えるなら
wikipediaの定義でもおかしくはない
(一般的かどうかはさておき)

あと何を誤解してると思ったのかは書いてもらわないとわからん

**デフォルトの名無しさん** · 2025/12/12(金) 23:45:04.62

>>133
1. ミューテックスと排他制御(mutual exclusion)を区別しよう
ミューテックスは排他制御を実現する方法の一つで
locked/unlockedの状態を管理する変数だったり構造体だったりの実装のこと
排他制御(mutual exclusion)という概念とは別もの

2. ワーカーを使わないシングルスレッドのJavaScriptにおいて排他制御は不要か？
もちろん必要
https://web.mit.edu/6.102/www/sp25/classes/16-mutual-exclusion/

3. ワーカーを使わないシングルスレッドのJavaScriptにおいてミューテックスは不要か？
ミューテックスが必要な状況ももちろんある
例えば複数のダウンロードリクエストを並行処理しているダウンローダーで
特定のサイトは最大1コネクションのダウンロードしか許可しておらず
複数同時ダウンロードをすると全部強制終了されてしまう状況とか

**デフォルトの名無しさん** · 2025/12/12(金) 23:59:32.76

>>149
無知だな
基本を分かっていない

ミューテックスはマルチスレッド時に同時アクセスの競合が起きる可能性がある場合に用いてスレッドを待たせる機能がある

特定のサイトは最大1コネクションのダウンロードしか許可してない場合
ワーカーを用いないJavaScriptは並行処理なのでミューテックスは不要
単なるカウンター変数のみでよい

**デフォルトの名無しさん** · 2025/12/13(土) 00:03:09.62

>>143
>並行処理＝同時進行するが同時に実行されることはない
>並列処理＝同時に実行されるためメモリ競合などの対策が必要
一般的な定義からすると↑これはどっちも間違ってる
並行処理は同時実行されてる部分もあれば同時実行できない部分ももある
同時実行できない部分の制御のため競合対策が必要

並列処理は同時実行可能な処理を指すので競合対策は不要
同時実行できない処理を並列処理とは普通は言わない

**デフォルトの名無しさん** · 2025/12/13(土) 00:07:42.28

>>151
wikipediaの記述やそこで引用している参考文献が正しい
あなたが間違っています

**デフォルトの名無しさん** · 2025/12/13(土) 00:07:52.21

>>150
>単なるカウンター変数のみでよい
それはカウンター変数をミューテックスとして利用しているってことなんだよ
>>149をもう1回読んでね

**デフォルトの名無しさん** · 2025/12/13(土) 00:36:34.04

現実的には単なるカウンター変数をミューテックスとして利用するだけではダウンローダーに必要な機能を満たせないからキューイングできるタイプの非同期ミューテックスを使う

**デフォルトの名無しさん** · 2025/12/13(土) 01:22:57.78

>>153
いいえカウンター変数とmutexは異なります
mutexは他のスレッドがロック中にスレッドを待たされる機能と利用が可能になったときに再開させる機能を伴います
その効率のためOSが提供するfutex機能を用いてmutexを実装する環境が多いです

**デフォルトの名無しさん** · 2025/12/13(土) 03:20:12.64

>>147
参照された記事には並行処理における競合対策は不要と記載されていました？

また、「コンピューティング」という、物理、実装を意識するレベルでの具体的差異をこちらは否定していない
その前段となる概念レベルの関係についての言及であり

>Concurrency is a broader concept that encompasses several related ideas, including:
>Parallelism (simultaneous execution on multiple processing units). Parallelism executes tasks independently on multiple CPU cores. Concurrency allows for multiple threads of control at the program level, which can use parallelism or time-slicing to perform these tasks. Programs may exhibit parallelism only, concurrency only, both parallelism and concurrency, neither.
https://en.wikipedia.org/wiki/Concurrency_%28computer_science%29#Related_concepts

実際に並行、並列処理の実装にあたっては、物理、ハードウェア的な制約に基づき、当然、両者は弁別される
言うまでもないがシングルコアにて並列処理は実装できまい
さりとて逆もしかりとならないわけで
前者は後者を包含している、後者は前者の下位概念であり、具体的な実現手段
「並行 ⊃ 並行、並列」のように概念のポケットに、それとは別に具体的技術としての「並行」「並列」が入るイメージ

そして繰り返すけど、本件論点は競合考慮、ミューテックスの要否では？
並行プログラミングする際、これを不要とする立場？

**デフォルトの名無しさん** · 2025/12/13(土) 07:39:32.48

>>156
並列を用いない場合＝マルチスレッドを用いない場合＝シングルスレッドの場合、
並行処理でメモリアクセスが同時に実行されることはないためメモリ競合は発生しない。
つまりカウンターやフラグなどあらゆる変数についてMutexを用いる必要がない。

これはJavaScriptだけでなくRustでシングルスレッドで非同期タスクを並行処理する場合も同じ。
具体的にはtokioのspawn (並行＆並列)はSendトレイト境界があるため変数共有にMutexなどが必須だが、
spawn_local (並行のみ)はSendトレイト境界がないためMutexは不要という形で表れる。

**デフォルトの名無しさん** · 2025/12/13(土) 08:07:26.77

関連型ってT<U>みたいな型依存型ができないからその代用だよね

**デフォルトの名無しさん** · 2025/12/13(土) 10:56:12.72

シングルスレッドでも２つの非同期処理がawaitを挟んで同じメモリを参照・更新する時は
data raceのリスクがあるから気をつけてくれ
Rustの場合は&mutが他の参照をブロックするから問題になりにくいけど

**デフォルトの名無しさん** · 2025/12/13(土) 11:00:34.93

日本語より
concurrent
parallel
distributed
で議論した方が良いと思うの
https://zenn.dev/koron/articles/3ddcaaeae37f9befdf70

**デフォルトの名無しさん** · 2025/12/13(土) 11:37:19.65

並行はヘテロ
並列はホモ

**デフォルトの名無しさん** · 2025/12/13(土) 12:58:20.04

同時アクセスの可能性があるものにmutexでロックかけろってだけじゃないの

**デフォルトの名無しさん** · 2025/12/13(土) 14:26:19.82

>>162
原則としてはそう。
ただ、データ競合は阻止できてもデッドロックは阻止できないし、性能的に改善できる余地もあるから唯一の正解というわけではない。

**デフォルトの名無しさん** · 2025/12/13(土) 14:26:52.20

>>162
Mutexは別々のスレッド同士が同時アクセスするデータ競合を防げるよ
通常のstd::sys::Mutexだと既にロックを持っている同じスレッドでロックしようとすると動作の保証はなくてパニックするかデッドロックするかなど環境依存なので用いてはダメだけど
つまりそれはマルチスレッド用

**デフォルトの名無しさん** · 2025/12/13(土) 14:48:01.82

一般的なアプリケーションプログラミングにおいては、排他制御の対象はデータというよりコードの特定のセクションであることが多い
当該セクションで扱うのが単一のデータストアである場合はそのデータストアに対する単純なロックに帰着するが、実際にはそうでない場合も多い

**デフォルトの名無しさん** · 2025/12/13(土) 15:10:49.43

ケントンプソンに書き直してもらったほうがいいだろこの言語

**デフォルトの名無しさん** · 2025/12/13(土) 20:30:59.61

自演するにしても、逆に自演ってバレバレになる1レスごとルーパチじゃなく
せめてWi-Fiとスマホ回線でやればいいのに