C++相談室 part150

**デフォルトの名無しさん** · 2020/03/24(火) 00:04:33.93

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part149
https://mevius.5ch.net/test/read.cgi/tech/1581974381/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

テンプレここまで

**デフォルトの名無しさん** · 2020/05/06(水) 19:48:49.83

同期がめっちゃ遅いから困ってんだってよ

**デフォルトの名無しさん** · 2020/05/06(水) 19:55:48.41

同期は遅くて当たり前だろ。
並列化したら速くなるとか同期コスト知らないIT音痴の妄想なんだから。

処理系依存していいならIntelのTSX試せよ。

**デフォルトの名無しさん** · 2020/05/06(水) 19:58:00.21

同期を速くするのは無理だぞ
高速化したければ同期を減らすんだぞ

**デフォルトの名無しさん** · 2020/05/06(水) 20:12:52.44

>>718
できるかどうかと
やるべきかどうか
は別の話
区別しようぜ

**843** · 2020/05/06(水) 21:51:51.19

Atomicの話と同期の話の区別も宜しくねw

**デフォルトの名無しさん** · 2020/05/06(水) 22:20:21.87

>>718
誰もdoubleで同期を取るなんて話はしてない
atomicなアクセスの話題

>>716
複数ならSIMDレジスタを使う
YMMなら4個、ZMMなら8個までatomic

**デフォルトの名無しさん** · 2020/05/07(木) 00:01:22.08

同期をとればatomicである必要はない
そういうことじゃないのか

**デフォルトの名無しさん** · 2020/05/07(木) 00:24:54.15

話をまとめるとこうなる。

・8byteの読み書き命令がatomicかどうかは処理系依存する話でC++の話ではない。スレチだが聞くならチップを指定して聞け。チップ仕様見れば答えは出る。議論の余地はない。
・8byteの読み書きを同期したい、atomicにしたい。OSの同期か適当な同期ライブラリ使え。悩む余地なし。
・atomicと同期は話は別だ　→ありえないw ハードでatomic命令の実装に同期が必要だし、ソフトの同期処理の実装にCPUのatomic命令を使う。atomicの実装を知りたければVHDLスレにでも行け。
・馬鹿は同期を理解できない←30年前から言われてる名言。C++スレでdoubleがatomicかというアホ質問自体が証左。

**デフォルトの名無しさん** · 2020/05/07(木) 01:03:56.90

EOF

**デフォルトの名無しさん** · 2020/05/07(木) 01:11:02.02

>>719
なんだ、そこにそのまま書いてあるじゃない。
つまり、alignされているなら quadword は atomically に Read/Write できる。
キャッシュラインの中に納まっているなら align されてなくても OK、と。
8.1.1 Guaranteed Atomic Operations
The Intel486 processor (and newer processors since) guarantees that
the following basic memory operations will
always be carried out atomically:
・Reading or writing a byte
・Reading or writing a word aligned on a 16-bit boundary
・Reading or writing a doubleword aligned on a 32-bit boundary

The Pentium processor (and newer processors since) guarantees that
the following additional memory operations will always be carried out
atomically:

・Reading or writing a quadword aligned on a 64-bit boundary 16-bit accesses to uncached memory locations that fit within a 32-bit data bus

The P6 family processors (and newer processors since) guarantee that the following additional memory operation will always be carried out atomically:
・Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line.

**デフォルトの名無しさん** · 2020/05/07(木) 06:07:03.34

>>611に対する回答は既に>>673で明確に示されて終わってる話。
それを急に同期の話と勘違いしてとんちんかんな蒸し返し方をした>>680がおかしい

**デフォルトの名無しさん** · 2020/05/07(木) 06:35:21.80

その486の話でいうと、当時、486は自己書き換えコードを駆逐した。Prefetchされたコードは非同期のまま実行されたからだ。Prefetchされたものはメモリではないと言い訳してもPGはそうは思ってないのだから高速なCPUだけ動かないコードがいっぱいあったわけだ。
結局、Intelが折れたのかPenから正しく同期されるようになった。TSXといいIntelも結構やらかしてるし、PICじゃ今でも同期エラッタてんこ盛り。MIPSの実装なんて言わずもがな。

**デフォルトの名無しさん** · 2020/05/07(木) 06:52:28.04

同期って用語の使い方に違和感があるなあ

**843** · 2020/05/07(木) 07:35:15.71

>>732
同意
そもそも486の時代に自己書き換えコードがいっぱいあったとかにわかに信じがたい

**デフォルトの名無しさん** · 2020/05/07(木) 08:02:12.59

8086時代は結構あった
古いコードのおもりをさせられた人は苦痛だったろうね
今よりはるかにパズルコードが多かったし

**デフォルトの名無しさん** · 2020/05/07(木) 08:27:36.65

>>730
atomic命令=排他制御(同期処理)された命令。同義。
doubleアクセスがatomicか知りたい=double値で同期したいと解釈するのは普通じゃないかな。
まぁatomicであろうとなかろうと、C/C++的にはOSの同期オブジェクト使えって結論になるわな。
マルチスレッドの再現性ないバグの99%は同期のおれおれ実装が原因だし。

**843** · 2020/05/07(木) 09:26:23.94

アトミックと排他制御と同期処理って同じじゃねーぞ
doubleでアトミックと言うのは例えば
double d = 1.23;
…
d = 2.34;
ってやった時にdが1.23と2.34以外の値にならない事を言う
どっちの値になるかまでを保証するわけじゃない

**デフォルトの名無しさん** · 2020/05/07(木) 09:34:04.25

何に基づいた主張なのかわからない
論拠も書くべき

**デフォルトの名無しさん** · 2020/05/07(木) 09:50:51.36

>>736
おれは同じ意味で使ってるし、
世界の技術者もそうだからボクたちに合わせてくれないかな。

**デフォルトの名無しさん** · 2020/05/07(木) 09:53:56.60

>>735
> まぁatomicであろうとなかろうと、C/C++的にはOSの同期オブジェクト使えって結論になるわな。

お前 ID:lE4/XlkX だよね？

**843** · 2020/05/07(木) 10:01:49.95

>>738
> おれは同じ意味で使ってるし、
それは勝手にしてくれ、どうせ人の言うことを聞かないだろうし
> 世界の技術者もそうだから
妄想乙w

**デフォルトの名無しさん** · 2020/05/07(木) 10:21:20.74

>>739
単発IDのくせにいなきり「お前」かよ。GWはほんと口の聞き方も知らないリアルクズ野郎ばかりだな。
おまえのような礼儀も知らず妄想しかできない低能クズに寛容なるおれ様が特別に教えてやろう。

違いますよ^^　礼儀を知らない馬鹿は二度とおれにレスすんなw

**デフォルトの名無しさん** · 2020/05/07(木) 10:32:16.12

同期とアトミックと排他制御が同じとは
ヤバいのがいるなこのスレ

ソフトウェアの基礎を学んだ方が良い

**デフォルトの名無しさん** · 2020/05/07(木) 10:36:17.88

個人的に並列化処理といえば、例えば2coreの場合、
double buf[1024];
の内の、0-511 までを core1、512-1023 までを core2で処理するものだと思っていた。
atomicであるかどうかを気にしている人は、
buf[0] を core1とcore2で
[core1]
for(・・・) {
　buf[0] += 1.0;
}
[core2]
for(・・・) {
　buf[0] += 1.0;
}
みたいに同時に書きこみたいと思っているの？？？？
でも、atomicというのは、書き込みのみ、または、読み込みのみ、のどちらかの
場合だと適用できるけど、↑のコードの場合、+= 演算子は、直前の値を読み取ってから、
1.0 を足して、同じ場所に書きこむ動作をするので、いくら、double値の書き込みが
atomicであっても、結果はめちゃくちゃになるよ。

**デフォルトの名無しさん** · 2020/05/07(木) 10:45:35.17

>>741
- std::atomicの使いどころを理解してない
- "OS"の同期プリミティブを使えと主張 (なぜOSと限定？)

この二つの条件を満たす別人が現れる確率は結構低いと思ったんでね
非礼の詫びとしてatomicの使いどころ知りたかったら教えてやるけどどう？

**デフォルトの名無しさん** · 2020/05/07(木) 10:50:13.38

>>743
そんなraceばりばりの例だめにきまってんじゃん
単純に一方がwriter、他方がreaderでもatomic性は必要でしょ

**843** · 2020/05/07(木) 11:13:09.18

>>743
> atomicであっても、結果はめちゃくちゃになるよ。
+= の話はレイヤーが違う
2 threadで元々0.0の変数に各々 += 1.0を10回実行した時に結果が20.0増えないことがあるって言う話をしてるんだろうけど結果は1.0~20.0に範囲になる
>>611のは浮動小数点フォーマットとして正しいかどうかもわからん

**デフォルトの名無しさん** · 2020/05/07(木) 11:20:48.41

std::atomic<double>はoperator+=ないね

**デフォルトの名無しさん** · 2020/05/07(木) 12:09:28.57

>>746
>>611のは浮動小数点フォーマットとして正しいかどうかもわからん
それも、個人的には分かっているつもり。

**デフォルトの名無しさん** · 2020/05/07(木) 12:11:04.76

>>745
>単純に一方がwriter、他方がreaderでもatomic性は必要でしょ
確かに必要だね。
でも、個人的には具体的にどういう利用例があるのか分からない。

**843** · 2020/05/07(木) 12:17:56.15

>>748-749
書き込みスレッドが書き込んでいるデータを読み出しスレッドが読み出して表示する
とかの場合アトミックでないと不正なデータを表示してしまう
計測器等でありがちな処理だよ

**デフォルトの名無しさん** · 2020/05/07(木) 12:53:58.73

>>749
一番原始的なスレッド通信

>>743
複数命令を使って事実上アトミックに出来るCPUもあるし
整数ならアトミック加算出来る命令があるCPUもある

ARMやMIPSは前者、x86は後者

**デフォルトの名無しさん** · 2020/05/07(木) 17:00:45.03

C++に限ったことじゃないかもしれないんですけど質問させてください
typedefで型に別名つけることについてです。今いじってるコードでたとえばvector<animal>にanimalsって型名をつけるようなのが山のようにあるんです
これすごくわかりにくいなと思います。例えばvector<animals>で宣言されてればその変数にどんな操作ができるのか一発ですが突然animalsで宣言されても何ができる型なのか初見では分かりません
別名をつけることがメリットになることってあるんでしょうか

**デフォルトの名無しさん** · 2020/05/07(木) 17:14:48.12

メリットは君が言ってる通り特定の言語に限った話では特定の回答は出て来ないし
言語を取り巻く環境(エディタや統合環境や諸々)でも答えは変わってくる

◆QZaw55cn4c · 2020/05/07(木) 18:04:16.36

>>752
using animals = std::vector<animal>;
わたしも、こういう typedef はしない方ですね、リッチなエディターを使っていないせいかもしれません
書いた人は別名を細かく付けた方がいいと考えているようですが、こういうのは記述の粒度の問題かもしれませんね

**デフォルトの名無しさん** · 2020/05/07(木) 18:08:47.80

>>752
例えば後からvectorじゃなくてlistにしたいなーと思ったときに修正箇所が一箇所で済む

**デフォルトの名無しさん** · 2020/05/07(木) 18:14:03.65

テンプレートで使うからでは。

**デフォルトの名無しさん** · 2020/05/07(木) 18:29:01.78

>>752
書くのが簡単になり、見るのも分かり易くなることがある。
また、animal_s とちゃんと最後に複数形を現す「_s」を付けるという
自分なりの命名規則を付けておけば、vector<animal> のことである
こともすぐに分かる。

**デフォルトの名無しさん** · 2020/05/07(木) 18:31:07.04

>>757
なお、型名は小文字ではなく、Animal か、CAnimal、TAnimal のようにするのが慣例。
vector<Animal> の場合、AnimalVector とすると、書くのも理解するのも楽になる。
templateのままをコード中に大量に書くとわずかな書き間違いで変な動作になりかねない。

**デフォルトの名無しさん** · 2020/05/07(木) 18:36:04.65

>>758
templateは、C++の中でも最も複雑で、書き間違えたときのエラーが理解しにくい
とされる部分。
だから、vector<Animal>とコードのそこかしこに書きまくるのはお勧めしない。
それと、<や> は、キーボードの配置からして打ち込みにくいという事情もある。
指が届きにくい場所にあるというか。
また、vector<Animal
と> を書き損じたような場合、>を探してコンパイラが変な場所でエラーを出して
しまい、どこでエラーが始まったか探し出すのに苦労するようなこともある。
だから、このような「組み立てられた型」は、毎度毎度そのまま使うと痛い目に
遭う可能性があるので、animals と typedef した人は賢い。

**デフォルトの名無しさん** · 2020/05/07(木) 18:37:12.86

>>744
レスするなと言ってるのにほんと人の話を聞いてないな。だから別人だって言ってるだろう。
std::atomicの使いどころってstd::atomicの話題に一度もレスしてないし、std::atomicの話を振られてもいない。

しかもOS限定とか妄想そのもの。
> OSの同期か適当な同期ライブラリ使え。悩む余地なし。
と最初に言ってる。逆にキミのその発言で、キミは今まで禄にコードを書いたことのない糞ガキの学生ということがよくわかったよ。

仮にOS提供の同期機構かstd::atomicかという選択であっても1nmもstd::atomicの選択余地はない。0%だ。
枯れてないライブラリは論外。同期バグはOr****やIntelでもやらかすし、枯れてるほうを使う。
何十年もカーネル開発者が注力し、コキ使われてきた実績のある同期コードを選ぶのがまともな社会人。
キミのような無責任な子供やテストしないOSSな人じゃないからね。OS提供がなくても同じ。
組み込み系ならチップメーカーが提供する同期ライブラリを使う。

**デフォルトの名無しさん** · 2020/05/07(木) 18:39:12.04

命名規則は、animals よりも、
vector<animal> の時には、AnimalVector
list<animal>の時は、AnimalList
とするのがお勧め。
最後の s だけだと、見落とす可能性があることと、集合体であることだけは
分かっても、それが、どんな種類の集合体かまでは分からないため。

**デフォルトの名無しさん** · 2020/05/07(木) 18:42:48.91

もうひとつ、vector<animal> より、AnimalVector とした方がいい理由は、
正規表現検索する場合のため。
正規表現だと、< や > は何らかの meta 表現的な意味を持っている場合があるかも
知れないので、型名は単純な alphabet 列の方が何かと便利。

**デフォルトの名無しさん** · 2020/05/07(木) 19:54:24.58

今どきシステムハンガリアンもどきなんてやだよぅ

**デフォルトの名無しさん** · 2020/05/07(木) 20:03:35.58

vectorからlistに変えられなくなる

◆QZaw55cn4c · 2020/05/07(木) 20:14:04.24

>>761
vector から list に変えるときに、名前もいちいち変えないといけないのだったら、その命名ルールは今いちですね…

**デフォルトの名無しさん** · 2020/05/07(木) 20:56:23.62

Animalsの話題はわたくしがC++最大の謎と呼ぶvector継承不可問題だ
Javaだと「class Animal extends ArrayList<Animal>{」とできる
でもC++だとvectorそのものの継承はデストラクタの関係で認められていない

つまりクラスを作るかtypedefするか、C++には2通りの解決方法が存在する

**デフォルトの名無しさん** · 2020/05/07(木) 21:04:23.79

自分作りゃいいだろ
コンテナくらい

**デフォルトの名無しさん** · 2020/05/07(木) 21:04:44.42

別にvector継承してもいいんだよ
protectedかprivate継承する分には何の問題もない
役には立たないけど

**デフォルトの名無しさん** · 2020/05/07(木) 21:07:22.98

この程度でs付け忘れるとか不注意にもほどがある

**デフォルトの名無しさん** · 2020/05/07(木) 21:10:02.94

いや、vectorは今となっては継承すべきでないってこともないだろ

**デフォルトの名無しさん** · 2020/05/07(木) 21:21:54.60

vector<>のデストラクタが仮想でないのは仕様の欠陥ですか？

**はちみつ餃子** ◆8X2XSCHEME · 2020/05/07(木) 21:30:23.98

注意深さに自信があるならデストラクタが virtual でないクラスを public 継承しても
それ自体は言語仕様には反しないけど、人間は間違うのでな……。

>>768
private 継承した上で外部から呼び出しを許すメンバ関数は using すればいい。
役に立たないということはないと思う。

**デフォルトの名無しさん** · 2020/05/08(金) 01:16:40.31

基本的なことだと思うけどよく
よくあるイベントループってどうやったらシンプルかつMT安全かつ効率的に実装できる？
次のような条件で
- qeueuが空ならwaitする
- qeueuにイベントが追加されたら直ちにおきてdispatchする
- dispatchに長い時間かかることもありえる
- add_eventは可能な限り短い処理で完了する。
- stopがよばれたらloopから直ちにぬける。dispatch中の場合は終わってから抜ける。

次に雰囲気コード書きます。

**デフォルトの名無しさん** · 2020/05/08(金) 01:21:33.28

loop()がこれではいかんのはわかってるけど、どうすれば簡潔に書けるのかわからん
他にもあやしいところがある気がする

bool running = true;
std::deque<int> unsafe_queue;
std::mutex mtx;
std::condition_variable cond;
using unique_lock = std::unique_lock<std::mutex>;
void stop() { running = false; }
void add_event(int i)
{
　　unique_lock _(mtx);
　　unsafe_queue.push_back(i);
　　cond.notify_one();
}
void dispatch(int) { /*do something*/ }
void loop()
{
　　unique_lock lock(mtx);
　　while (running) {
　　　　cond.wait(lock, [] { return !unsafe_queue.empty(); });
　　　　auto ev = unsafe_queue.front();
　　　　unsafe_queue.pop_front();
　　　　dispatch(ev);
　　}
}

**デフォルトの名無しさん** · 2020/05/08(金) 03:21:51.97

まずconcurrent_queueを持ってくるなり作るなりして用意した方がいいよ
イベントループにロックやイベント混ぜて書くとわけわからなくなる

**デフォルトの名無しさん** · 2020/05/08(金) 03:34:19.21

イベントって同期イベントね

**デフォルトの名無しさん** · 2020/05/08(金) 03:38:35.90

concurrent_queueは必要ないと言うかこの用途だと無駄な処理増えるだけじゃね

**843** · 2020/05/08(金) 05:40:01.72

>>773
BlockingCollection使えばいいだけじゃねーの？

**デフォルトの名無しさん** · 2020/05/08(金) 06:51:21.78

>>774
それ、イベント発行しないと止まらなくね？

**デフォルトの名無しさん** · 2020/05/08(金) 11:45:01.04

>>775
concurrent_queueって標準であります？どれのこと？
MT安全なqueueクラスを作ると
イベント待ちしてるときのstopで即終了が面倒かなと思いました

**デフォルトの名無しさん** · 2020/05/08(金) 12:06:11.41

>>779
そうなんですよね
runningのチェックって一回のままで実現できないですかね？

**デフォルトの名無しさん** · 2020/05/08(金) 12:18:21.10

>>778
BlockingCollectionってどこにあります？
ぐぐったらC#のクラスは見つかりましたが
上に書いた通り、stop時の処理がまわりくどくなりそうなのを気にしてます
実行時のロジックがシンプルなやり方を追求したいです

**843** · 2020/05/08(金) 12:23:41.84

>>782
> BlockingCollectionってどこにあります？
> ぐぐったらC#のクラスは見つかりましたが
触れちゃ駄目な人だったか…

**デフォルトの名無しさん** · 2020/05/08(金) 12:39:35.76

普通は終了を意味する番兵オブジェクトを用意するんじゃないの
キューの中身を最後まで処理して欲しいなら単に番兵を積めばいいし、無理矢理終わらせたいならキューを強制的に空にしてから番兵放り込めばいい

**デフォルトの名無しさん** · 2020/05/08(金) 13:50:27.60

>>784
なるほどそれだときれいに書けますね
runningフラグは不要にできると

しかしわりとクリティカルな処理を想定してるので
stopを呼ぶスレッドで(イベントオブジェクトの)解放処理が起るのは問題に
なるかもしれないです(例ではintですが実際はもうちょっと凝った構造体)
runningフラグ前提だときれいに書けないですかね？

**デフォルトの名無しさん** · 2020/05/08(金) 17:13:05.00

こんなんでいいのでは。running2回チェックは避けられそうにないなあ。チェックよろ
start() {
{
lock()
running = true
}
run(loop)
}
stop() {
{
lock()
running = false
}
notify()
join()
}
loop() {
lock()
while(true) {
cond_wait(!empty() or !running)
if (!running) {
break
}
pop()
}
}

**デフォルトの名無しさん** · 2020/05/08(金) 17:29:10.43

スレッド動作トリガーはcond 1個にして
スレッド内で、キューやrunningフラグを見る

**デフォルトの名無しさん** · 2020/05/08(金) 17:32:31.56

Windowsみたいな高機能な同期が有れば
イベント、タイマー、ファイルアクセス、ネットワーク通信
などなど色々な物を同時にトリガーに出来る

linux系はその辺が貧弱
スレッドを動かす為のスレッドが必要になったりする

**デフォルトの名無しさん** · 2020/05/08(金) 17:46:30.97

>>788
全部selectやepollでまとめて待てるけど、winはもっと高機能なん？

**デフォルトの名無しさん** · 2020/05/08(金) 18:43:53.40

yes

**デフォルトの名無しさん** · 2020/05/08(金) 19:10:58.40

>>786
インデントつけました

void loop() {
　　lock()
　　while (true) {
　　　　cond_wait(!empty() or !running)
　　　　if (!running) {
　　　　　　break
　　　　}
　　　　pop()
　　}
}

cond_waitの前にrunningみなくて大丈夫ですかね？
startの直後loopが始まる直前でstopが呼ばれた場合cond_waitって起きます？

**デフォルトの名無しさん** · 2020/05/08(金) 19:27:16.63

>>790
違いは同期オブジェクトを含められるかどうかぐらいでは？
それ以外ならlinuxでもたいていfdになってる
少なくとも>>788の後ろ三つは可能
イベントもパイプで代用できることが多い

**デフォルトの名無しさん** · 2020/05/08(金) 20:07:48.20

>>791
cond.waitはブロックする前に一度条件式を確認する動きになってる。
条件式が初めからtrueであればそもそもブロッキングをしないからcond.waitの前にrunningをみなくても大丈夫だと思う

**デフォルトの名無しさん** · 2020/05/08(金) 20:36:08.72

>>793
そうでしたか
ありがとう

**デフォルトの名無しさん** · 2020/05/08(金) 22:51:30.97

もうひとつ質問させてください
>>774 のrunningはstd::atomic_boolにする必要はあります？

C言語だとこの手の変数はvolatileにすると思うのですが
C++ならatomicでしょうか？
上の方でatomicのこといろいろ書いてありますがこの場合はどうなんでしょう？

**デフォルトの名無しさん** · 2020/05/09(土) 00:53:16.27

void Foo::pushReq(const XXXReq& req)
{
　EnterCriticalSection(&m_csec);
　{
　　if (!m_bTerminate) {
　　　m_requests.push(req);
　　　SetEvent(m_hEvtNewRequest);
　　}
　}
　LeaveCriticalSection(&m_csec);
}

**デフォルトの名無しさん** · 2020/05/09(土) 00:57:33.61

bool Foo::popReq(XXXReq& req)
　for (;;) {
　　if (!m_bInOperation) {
　　　// イベント待機
　　　WaitForSingleObject(m_hEvtNewRequest, INFINITE);
　　　if (m_bTerminate) {
　　　　return false;
　　　}
　　　m_bInOperation = true;
　　} else {
　　　EnterCriticalSection(&m_csec);
　　　{
　　　　if (m_requests.empty()) {
　　　　　m_bInOperation = false;
　　　　　// 今入っているイベントはbInProcess中に入ったもので
　　　　　// 明らかに古いのでリセット
　　　　　ResetEvent(m_hEvtNewRequest);
　　　　} else {
　　　　　// 要求があればpopして処理
　　　　　req = m_requests.front();
　　　　　m_requests.pop();
　　　　}
　　　}
　　　LeaveCriticalSection(&m_csec);

　　　if (m_bInOperation) {
　　　　// 処理すべきリクエスト有り
　　　　break;
　　　}
　　}
　}
}

**デフォルトの名無しさん** · 2020/05/09(土) 01:01:13.28

ウィンドーズの同期APIの仕様により
同期API呼び出し時点であらゆる変数のメモリへの書込みとメモリからの読み込みが完了するので
とくにvolatileは不要
なはず、

**デフォルトの名無しさん** · 2020/05/09(土) 06:06:39.41

>>795
>>786のようにrunningの更新をlockで保護するのであればatomic_boolにする必要はないと思うよ
void stop() {
　　std::lock_guard<std::mutex> lk(mtx);
　　running = false;
　　cond.notify_all();
}
お手本でも普通のboolを使ってる
https://cpprefjp.github.io/reference/condition_variable/condition_variable.html
https://cpprefjp.github.io/article/lib/how_to_use_cv.html

**デフォルトの名無しさん** · 2020/05/09(土) 11:17:56.00

>>799
loop()内のrunningは毎度メモリから読まれる必要があるので
C言語ならvolatileにすると理解しています
つまりループ内で最適化されてしまわないようにするためだと思います

これがC++だと仕様的にもともと問題ないのでしょうか？
逆に最適化がかかりにくくなってしまう気がします
ただ手元で実装したものは最適化かけていても確かに期待通り動いています

**デフォルトの名無しさん** · 2020/05/09(土) 12:59:28.79

>>800
POSIX準拠のシステムでは同時アクセスを防ぐ書き方(mutexによるlockとかstd::atomicによるstore/loadとか)
をすれば自動的にメモリ同期(メモリへのフラッシュ)が行われる作りになっていてvolatileとかを気にする必要がないらしい
https://yupo5656.hatenadiary.org/entry/20040618/p2

**デフォルトの名無しさん** · 2020/05/09(土) 13:06:53.14

>>800
>>774のコードの全体の当否はおくとして
while()の中でlockしているのであればlockされるブロックに出入りする際に
>runningは毎度メモリから読まれる
が実現されるからrunningフラグはvolatile無しでもむ無問題、

C++の標準的なlockの仕様は知らんがlockに出入りするときに
CPUのライトキューやリードキューに未処理のライトコマンドやリードコマンドが乗ったままだと
正しいロックにならないから普通のlockの実装ではメモリバリアを行う

メモリバリアはコンパイラに対してはイントリンシックな関数か何かとして定義されており、
それらの呼び出しのときコンパイラは空気を読んでレジスタに乗ったままの変数を放置しないはず…
（変数に対する副作用がある関数呼び出しとみなす

**デフォルトの名無しさん** · 2020/05/09(土) 13:16:40.60

POSIXスレッドはetchになってからようやく使い物になった
woody以前は酷い出来だったのは酔い思い出

**デフォルトの名無しさん** · 2020/05/09(土) 13:46:46.99

しかし以下のような実装のときrunningにvolatileが本当に要らないかどうかわわからん…

void bar() { (内部でlockを行う) }

====↓↓↓異なる翻訳単位↓↓↓====

void foo {
　bool running = false;　　// runningはローカル変数
　while (running) {
　　bar();　　// 一見runninguへの副作用が考えられないシグネチャ
　}
}

どうやっているのかは知らんが、ウィンドーズの同期系API（上の例でbar()にあたる）は
うまいことやってくれる（と思う！

◆QZaw55cn4c · 2020/05/09(土) 13:51:04.20

>>801
というか、pthread や pthread 採用の C++11orlater で記述するのが普通です
volatile のみでなんとかするようなものじゃない

**デフォルトの名無しさん** · 2020/05/09(土) 13:52:06.16

よく考えたら上のコードではrunningへのポインタを他のスレッドが知っていることもありえないから、
そういう意味でvolatile不要（最適化上等）か…orz

一方、runningがグローバル変数なら、異なる翻訳系で定義された関数を呼び出した後に、
runningは改めてメモリから読まれることはコンパイラが生成するコードの規定の動作なので
volatile不要

まとめると、runningがグローバル変数でありかつ同期目的の関数内でメモリフェンスしており、
かつそこが毎回通る限り、runningにvolatileは不要

**デフォルトの名無しさん** · 2020/05/09(土) 13:53:07.30

>>804
running がローカル変数なら bar() での副作用は無理だから volatile の有無によらず foo() は空にできちゃうのでは？

**デフォルトの名無しさん** · 2020/05/09(土) 13:54:44.10

（リロードしてなかった・・・）
>>806 つまり volatile が必要なケースは無いね？

**デフォルトの名無しさん** · 2020/05/09(土) 14:01:00.47

>>808
多分、orz
計算機科学や実際のプログラムの実装は複雑怪奇なので、
病的な反例が何かあるかも((((;ﾟДﾟ))))ｶﾞｸｶﾞｸ

**デフォルトの名無しさん** · 2020/05/09(土) 14:22:58.21

>>801
それはメモリバリアのことですよね
つまりCPU内のリオーダーの制御で
lockからunlcokまでメモリアクセスはその外にリオーダーされることがない

>>800 で気にしてるのはそれではないです
レスわけます

**デフォルトの名無しさん** · 2020/05/09(土) 14:32:48.74

>>802
> >>800
> >>774のコードの全体の当否はおくとして
> while()の中でlockしているのであればlockされるブロックに出入りする際に
> >runningは毎度メモリから読まれる
> が実現されるからrunningフラグはvolatile無しでもむ無問題、

一度目はメモリから読まれるのは確実だと思います
ただループの場合、2度目のリードからはコンパイラが最適化をかけて
一度目の値を使いまわす可能性があると思います

void loop()
{
　　unique_lock lock(mtx);
　　auto r = running
　　while (r) {
　　　　....
　　}
}

と置き換えてしまう可能性があるのでは？ということを心配しています
私のC言語開発の経験ではこの場合はvolatileにするのが鉄則でした

c++のコンパイラはかしこくrunningは都度メモリから読み出すべしと判断していると
なるとその判定はどうやって行っているのでしょう？
一律にローカル変数以外はメモリから呼び出すわけではないと思います
(それだとかなり性能が落ちると思います)

**デフォルトの名無しさん** · 2020/05/09(土) 14:56:31.18

>>811
コンパイラ視点で見れば中身のわからないcond.wait()と言う関数呼び出しが
グローバル変数runningに対する副作用を持たない（値を書き換えない）ことの保証が無いから、
cond.wait()をループ外にくくりだす最適化が行われることは普通は無い。 --- （A）
また、ソースコード上cond.wait()を呼び出した後にrunningを参照する箇所があれば、
普通はかならずメモリからrunningを読み直すコードが吐かれる　--- （B）

普通でない場合というのはコンパイラがcond.wait()メソッドの中身まで知っていて
runningに対する副作用が無いと結論付ける場合が考えられるが、
それでもcond.wait()の中で
　(1) メモリバリアを行っており、
　(2) その意味をコンパイラが知っている
限り、コンパイラが「（cond.wait()呼び出しによる）runningに対する副作用が無い」と結論付けることはありえない --- (C)

というわけで、普通は(A)、(B)が成立するからrunningのvolatileは不要
(A)、(B)非成立な変に賢いコンパイラでも、(1)と(2)が成立するなら(C)が成立するからrunningのvolatileは不要

**デフォルトの名無しさん** · 2020/05/09(土) 15:08:39.92

>>811
ループは>>791の方法で行くんじゃなかったの

**デフォルトの名無しさん** · 2020/05/09(土) 15:08:46.08

>>812
それはstd:::condition_variableを使った場合に限定していますか？
基本的にpthreadのwrapperだと思うのですが、仮にコンパイラがそれを特別扱いしているとすると
pthreadをダイレクトに使った場合はどうなりますか？
あと客観的な文献を示してほしいです

**デフォルトの名無しさん** · 2020/05/09(土) 15:11:10.97

>>813
そうですが別の話題なのでわかりやすく書きました
ただ >>791 もイベント処理中はunlockしておく必要があったのでそこは変えました

**デフォルトの名無しさん** · 2020/05/09(土) 15:20:05.99

>>815
それだと>>811のコードでwhile(r) (あるいはwhile(running))ってなってるのがわからない
>>791だとwhile(true)の中でif(!running)ならbreakするって形でそもそもrunningは一回しか評価しないはず

**デフォルトの名無しさん** · 2020/05/09(土) 15:38:10.36

>>814
>それはstd:::condition_variableを使った場合に限定していますか？
いいえ

>pthreadをダイレクトに使った場合はどうなりますか？
どう使うつもりかわわからんが、コンパイラに中身を知りようが無い関数の
呼び出しがループ内に生じる限り同じ話

>客観的な文献を示してほしいです
(1) 変数に対する副作用がある（かもしれない）関数がループ外にくくりだされないこと
　コンパイラはソースコードをオブジェクトコードに翻訳する際、
　ソースコードに書かれたアルゴリズム（有限ステップで終わる＆非同期要素無し）の
　動作結果を変えてはならない。この原則はコンパイラの教科書に書いてあるし常識と言っても過言ではない
　で、変数に対する副作用がある（かもしれない）関数の不適切な最適化はこの原則にひっかかる

(2) 少なくともMSVCがメモリバリアの意味を知っている根拠
https://docs.microsoft.com/ja-jp/cpp/intrinsics/readwritebarrier?view=vs-2015
これ、VS2010までは非推奨ではなかったし、サンプルコードも載っていたが無くなってたorz

**デフォルトの名無しさん** · 2020/05/09(土) 15:40:22.80

>>814
標準スレッドライブラリを使った前後の読み書きについては、
ライブラリ関数呼び出し（ lock/unlock など）が提供するスレッドをまたぐ "synchronize with" 関係と
スレッド内での, "sequenced before/after" による前後関係とをつないだ
"inter-thread happens before" 関係（順序付け）に基づく挙動が規定されている。
https://timsong-cpp.github.io/cppwp/n4659/intro.multithread#intro.races-9
>811 のような書き換えは許されない。

規格化以前の pthread などをダイレクトに使った場合は >>812 の挙げるような
「事実上問題にならない」に頼ることになり、これに volatile を加えても「事実上問題にならない」の
範疇であることに変わりはない。
問題の可能性が減ったり、実際に起こっていた問題の解決につながることはあっただろうけどね。
これについては「客観的な文献」といったものが無かったことも規格化の動機になっただろう。
https://isocpp.org/wiki/faq/cpp11#cpp11-specific-goals
> - Machine model and concurrency ? provide stronger guarantees for and better facilities
> for using modern hardware (e.g. multicores and weakly coherent memory models). ...

**デフォルトの名無しさん** · 2020/05/09(土) 16:27:23.02

>>817
なるほど
つまりc/c++コンパイラの最適化において、
副作用がある(pure functionでない)関数があると、それをまたいだ
リオーダーや値の流用をすることはない

当然メモリバリアを張るcond(pthreadも含む)は副作用ありなので
これがループ中に存在する場合はrunningは毎度メモリから読み出されることになる

ということですね
非常によくわかりました