GLOBAL_DEFINED_WORDS: 同期に関する操作の2項関係たちを追加

[akinomyoga]

取り敢えず暫定的に作っておきます。実際の変更は、全く違う形もアリだと思っています (例えば無理に日本語にするのはやめて happens before, strongly happens before, synchronizes with, etc. で通すなど)。あと説明はもっとちゃんとしたものがあれば提案していただければ幸いです。

---

#1359 (comment) by @yohhoy

弱い意見として、「同期」の説明はしなくても良い気がしています。

• C++標準ライブラリ仕様記述の Synchronization は、マルチスレッドプログラミングの文脈でいう同単語の一般的な用法とニュアンスが異なる。（C++では"happens before"関係を保証する、という意味で使われる）
• （少なくとも自分の感覚では）「リソースの所有権」はスレッド間同期との直接的な関係を持たない。

...

#1359 (comment) by @akinomyoga

うーん。synchronizes with の訳語として、既に太字 **同期する** というのが使われているみたいですね (でも、単に "同期" だったら cpprefjp 内で雑多な意味で使われている印象)。

• Code search results

この A は B と**同期する** というのは単なる一般の同期の話ではなくて、特に定義された関係 synchronizes with を表すので配慮が必要ですね。"同期する" も GLOBAL_DEFINED_WORDS に登録する? でも "同期する" はストリームが同期するなど別の文脈でも使われている?

Edit: happens before の訳は散らかっています:

• Code search results

この PR で "同期" を入れるか入れないかに関わらず、 synchronizes with および happens before の訳統一と訳語表と GLOBAL_DEFINED_WORDS への登録は独立に実施する必要がある気がします。

[yohhoy]

C++23仕様から、本件Issueで扱うであろう用語群を列挙しておきます。厳密な仕様説明をしない前提であれば "happens before" ＝ "synchronize with" ＋ "sequenced before" とみなせるので、この3語だけでも十分かもしれません。

• synchronize with
• happens before
• simply happens before：C++23現在は利用推奨されないconsume操作を無視すれば、happens beforeと同一
• strongly happens before：atomic操作のデフォルトseq_cstだけを使うなら、happens beforeと同一

以下は芋づる式に登場する2項関係：

• sequenced before：同一スレッド上の2項関係だが、xxx happens before定義の構成要素
• inter-thread happens before：happens before定義の構成要素
• dependency-ordered before：inter-thread happens before定義の構成要素
• carries a dependency：dependency-ordered before定義の構成要素

[akinomyoga]

sequenced before は cpprefjp で既に使われていますね…

• sequenced before → Code search results (これで全部かは分からない)

他の ～ before と carries a dependency は cpprefjp で使われている (or 将来使われることはある) でしょうか。

GLOBAL_DEFINED_WORDS は (現状) 自動マークアップ用なので cpprefjp で使われないものを頑張って登録する必要もないといえばない (とはいえ、将来的に用語集ページを生成するのに使うのであればユーザー目線で知っておくと良さそうなものについては今から入れておいても良い) ような気がします。

sequenced before 繋がりで他にも色々の sequenced の変種があったような…

• indeterminately sequenced → Code search results (これで全部かは分からない)
• sequenced after → cpprefjp では使われていない?
• unsequenced → cpprefjp では使われていない?

[yohhoy]

参考情報として、他プログラミング言語や他サイトでの "happens before" 訳出例を拾ってみました。

ちなみに、自分が同単語を扱うときは "訳さない" という選択をとっています。どうしても専門用語ぽさのない動詞句になるため、いっそ原単語のままとして目立たせておこう、という心情ですね。

Javaライブラリドキュメント

https://docs.oracle.com/javase/jp/8/docs/api/java/util/concurrent/package-summary.html

Java言語仕様の第17章では、共有変数の読取りや書込みなどのメモリー操作に関する happens-before関係 が定義されています。あるスレッドによる書込みの結果が別のスレッドによる読取りで認識されることが保証されるのは、その書込み操作が読取り操作の 前に発生(happens-before)した 場合だけです。synchronized構文とvolatile構文のほか、Thread.start()メソッドとThread.join()メソッドが happens-before関係 を形成できます。(略)

Java言語規定

https://thinkit.co.jp/cert/article/0711/5/3/2.htm

確かに先ほどの例では、共有している変数（AやB）に対して書き込みをしていました。そして、「17.4.5 Happens-before Order（ 先行発生 の順序）」には次のようにあります。

If we have two actions x and y, we write hb(x, y) to indicate that x happens-before y.（訳：二つの動作x、yがある場合、xがyより 先行発生する ことを示すためにhb(x、y)と記述する）。

http://www.y-adagio.com/public/standards/tr_javalang2/memory.doc.html#28920 （相当古い仕様のようで対応原文不明）

(略) 次の規則の大半は，ある特定の動作の実行における順序をさらに制約する。規則は，ある動作が他の動作の前又は後で行われねばならないことを規定している。この関係は，推移的とする。つまり，動作 A が動作 B に 先行 しなければならず，動作 B が動作 C に 先行 しなければならないならば，動作 A は，動作 C に 先行 しなければならない。(略)

Go言語ドキュメント

http://go.shibu.jp/go_mem.html

参照および更新の要求仕様を示すため、Go言語プログラムでのメモリ操作実行に関する部分的な順序関係、happens-before を定義します。イベント e 1がイベント e 2より 前に発生する 場合、 e 2は e 1の後に発生すると言えます。また、 e 1が e 2の前に発生せず、 e 2の後に発生しない場合、 e 1と e 2は同時に発生すると言えます。(略)

https://go-review.googlesource.com/c/go/+/381315/9/doc/go_mem.html Go1.19での改定前バージョン

To specify the requirements of reads and writes, we define happens before, a partial order on the execution of memory operations in a Go program. If event e1 happens before event e2, then we say that e2 happens after e1.
Also, if e1 does not happen before e2 and does not happen after e2, then we say that e1 and e2 happen concurrently. [...]

[faithandbrave]

こちらのPRも状況がよくわかってないので教えてください

[akinomyoga]

rebase しました。

こちらのPRも状況がよくわかってないので教えてください

以下の点について議論が必要と考えています。

日本語名称 vs 英語名称

冒頭に書いた通り、取り敢えず日本語の名称を用事する形で作りましたが、他の可能性として「happens before 関係」「strongly happens before 関係」「synchronizes with 関係」など英語にしてより用語感を出すという方向性もあって、個人的には決めかねています。既にコメントなどいただきましたが、日本語 vs 英語 については議論はされていません。

• 留意点: 日本語だとそれが用語であるということが分かりにくい (サイト上では GLOBAL_DEFINED_WORDS 修飾があるからOK)。また、翻訳時に微妙な表記の違いで修飾が適用されなくなる: 例 ○「に対して同期する」✕「にたいして同期する」
• 留意点: 非対称な関係を「に対して同期する」で表現する場合、英語「に対して synchronizes with 関係である」は分かりにくい。

記事で未使用の関連語も登録するか (#1360 (comment), #1360 (comment))

現状の PR の変更内容では synchronizes with, happens before, strongly happens before の3種類の関係が GLOBAL_DEFINED_WORDS に登録されています。一方で関連する関係として simply happens before があります。更に評価順序などの関係も芋づる式に関わってきます。sequenced before, inter-thread happens before, dependency-ordered before, carries a dependency, sequenced after, indeterminately sequenced, unsequenced

ここでの論点は GLOBAL_DEFINED_WORDS に cpprefjp の記事中で使われていない語も登録するか? ということです。

• 留意点: 現状ではユーザーの目に触れることはない。変換に使用する正規表現が重くなるだけ。
• 留意点: 将来的に短い用語集を自動生成するならば今の内に登録しておいても良い。

[faithandbrave]

現状まとめ、ありがとうございます。
C++用語というより分野の専門用語ということであれば、無理に訳さなくてもいい気はしますね。

未使用の用語は、用語解説ページとか作ればあってもいい気はしますが、ユーザー向けというわけでもなさそうであれば、GitHub Wikiにメモとしてとりあえず置いておいてもいいかもですね。

[github-actions]

⚡ プレビュー (HTML) (更新時刻: 2025-01-14 15:12:41 JST)

• ⫯ Commit: 176b16e
• プレビューの生成には時間がかかります (3～5分)。進捗状況はこちらをご確認ください。

変更記事一覧

• 📝 reference/atomic/memory_order
• 📝 reference/barrier/barrier
• 📝 reference/syncstream/basic_syncbuf/emit
• 📝 reference/thread/jthread/join
• 📝 reference/thread/jthread/op_constructor
• 📝 reference/thread/this_thread/sleep_for
• 📝 reference/thread/this_thread/sleep_until
• 📝 reference/thread/this_thread/yield
• 📝 reference/thread/thread/join
• 📝 reference/thread/thread/op_constructor
• 📝 working_style

※ソース (.md) に直接変更のあった記事を列挙しています。グローバル修飾や変換規則の変更による変化は考慮していません。

[faithandbrave]

追加でコメントがなさそうであれば、一旦マージして残りは別issueにして置いておくのがいいでしょうかね

[akinomyoga]

承知しました。私は問題ありません。非対称な関係の読者に対するわかりやすさを考えると、やはり日本語がいいかなというように感じています。後は「よりも先行発生」などの表現に置き換える案がありますが、取り敢えずこの PR では保守的な変更 (既存の記事に含まれていた表現に近い形) に留めることにします。

現状だと "**よりも確実に前に発生する**" などの記述に対して、"太字" かつ "GLOBAL_DEFINED_WORD としての修飾" になっていて、ページ上の見た目が過剰な気がするので太字を外そうかなとも思ったのですが、やっぱりやめます。太字にしていないと、.md を編集する時にそれが用語であるということに気づかずに日本語として編集して修飾が壊れてしまうということがあるかもしれないからです。

[faithandbrave]

異論がでないならとりあえず @akinomyoga さんの判断で進めていただいて、後々の新たなメンバや新たな視点で異論がでたりしたら相談する、というのでも大丈夫です。

[akinomyoga]

取り敢えずの形として現状でマージOKです。二三日待って他の方から意見がなければマージしますね。

---

それはそれとして本当は評価順序や同期についての包括的な記事もあった方が助かるのだとは思います。読者層によるとは言え、寧ろ初心者にとってこそ、規格に当たることなく難しいことを俯瞰できる日本語の情報には価値があるのでは、と (そして自分も読みたい)。