C++相談室 part156

**デフォルトの名無しさん** · 2021/05/19(水) 10:55:13.24

前スレ
C++相談室 part155
https://mevius.5ch.net/test/read.cgi/tech/1616555235/

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/08(日) 17:22:47.83

>>979
言葉の様子からは昔の C++ (C++03 以前) は使ってたのかな？
と推察するけど、 C++03 と C++11 の間では大きな飛躍があって、
その後も変更は色々あるのでちょっとしたことをいちいち質問するのは効率悪いと思う。

ドキュメントを網羅的にわかりやすく整理しているとてもありがたいサイトがいくつかあって
仕様改定がどういうものだったのかもまとまっているので参考にするといいよ。

https://cpprefjp.github.io/lang/cpp11.html
https://ja.cppreference.com/w/cpp/11

**デフォルトの名無しさん** · 2021/08/08(日) 19:31:37.38

std::threadってなぜかスレッドが実行中かどうかを調べるだけの関数がないんだよね
絶対にあった方が良いと思うんだけどなんか理由があるのかな

**デフォルトの名無しさん** · 2021/08/08(日) 19:40:44.42

joinableだけじゃ足りん？

**デフォルトの名無しさん** · 2021/08/08(日) 19:45:39.50

pthreadsにそういうAPIが無いからなぁ

**デフォルトの名無しさん** · 2021/08/08(日) 19:55:15.31

pthread_timedjoin_np()使えばいいじゃない

**デフォルトの名無しさん** · 2021/08/08(日) 20:02:19.74

none portableじゃないですかやーだー (でも使う)

標準としては難しそう

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/08(日) 20:27:26.52

native handleをgetしてWaitForSingleObject使うとか

**デフォルトの名無しさん** · 2021/08/08(日) 20:52:17.07

>>985
nandemo portable の略だから大丈夫

**デフォルトの名無しさん** · 2021/08/08(日) 21:39:14.34

普通にミューテックスで排他して状態管理せよ……
だいたいスレッドが動いているかどうかという1 bitだけを外部が欲しがるという用途は（join操作そのものを除き）あんま無く、
キュー的なﾌﾞﾂに対するデータの排他的な出し入れが普通伴うはず……

**デフォルトの名無しさん** · 2021/08/08(日) 21:44:02.93

ミューテックスで数千クロックサイクル浪費するのが嫌という向きは知らん
スピンロックとかdouble-checking lockみたいな対策になるかと思うが絶対安全かつポータブルな
方法というものは無くなる希ガス

**デフォルトの名無しさん** · 2021/08/08(日) 22:18:09.18

>>988
速度重視でmap/unordered_mapでコンテナ作ってみたけどやっぱり仕様変更に耐えられるvector/listコンテナ最強的なオチに似たものある

**デフォルトの名無しさん** · 2021/08/08(日) 22:43:58.32

キューへの投入と取り出しがそれぞれ1スレッドだけならミューテックスを使わなくてもアトミック変数だけで排他出来る(OSに仲裁してもらわなくていい)

**デフォルトの名無しさん** · 2021/08/08(日) 23:27:24.23

OSの助けなしにどうやって待ち（と起床）を実現するつもりなんじゃ……

**デフォルトの名無しさん** · 2021/08/08(日) 23:43:25.11

スレッドが実行中か確認したいってどんなときなのかな？
確認したところで次の瞬間には終了してる可能性あるわけじゃん
終了を待機したいならjoinすればいいし実行中をなんのために確認したいのかよくわからん

**デフォルトの名無しさん** · 2021/08/09(月) 00:16:27.81

Linuxのpthread_mutexの実装で使われているfutexも競合しないタイミングならユーザランドだけで処理が完結する (OSが仲裁する必要があるのは競合する場合だけ)

> Futex operation occurs entirely in user space for the
> noncontended case. The kernel is involved only to arbitrate the
> contended case. As any sane design will strive for
> noncontention, futexes are also optimized for this situation.
>
> https://man7.org/linux/man-pages/man7/futex.7.html

キューが固定長, 投入スレッド1つ, 取り出しスレッド1つという条件でならアトミック変数2つ(読み出し位置, 書き込み位置)で「競合しない」ように出来るので, OSの仲裁が必要じゃなくなる

**デフォルトの名無しさん** · 2021/08/09(月) 00:22:59.44

あと(pthread_mutexのようなネイティブの)mutexはそういう理由で大抵の場合は最速のロック機構になっているので, 自分で作るなら普通にmutex使った方がいいというのは同意
素人(俺とか)の考えたロックフリーデータ構造とか大抵設計か実装かその両方でバグが入る

**デフォルトの名無しさん** · 2021/08/09(月) 07:54:40.07

>>989
mutexが遅くてイヤならatomicじゃね？

**デフォルトの名無しさん** · 2021/08/09(月) 09:47:15.53

>スレッドが実行中か確認したいってどんなときなのかな？
排他制御付きのキューを自力実装するときまれによくある……
キューがあふれそうになったときpushする側（producer）を待たせる作りにした場合、
popする側（consumer）はデータをpop後、producerが待っていたらその待ちを解除、
待っていなかったら何もしないという判断が居るのでこのためのフラグ
（producer側にpushを継続する意思があるかどうか、またはpush待ち中かどうかを表すフラグ）が居る

producerよりconsumerがいつも速い見込みでキューがあふれない前提（キューが必要に応じていくらでも大きくなる）
だったりその他（待ち解除が条件変数ではなくキューイングされるイベントだったり）だと無くてもよいから
ぜってー必要か、というとﾋﾞﾐｮｰだがあった方がすっきり効率的なコードとして書ける

**デフォルトの名無しさん** · 2021/08/09(月) 09:51:30.16

>>996
インターロックドインクリメントはまれによく使う
インクリメントに性交したら排他的操作権を獲得できた証、

**デフォルトの名無しさん** · 2021/08/09(月) 09:55:16.95

となるようにインクリメントするカウンタの意味を仕向ける

**デフォルトの名無しさん** · 2021/08/09(月) 09:55:21.66

>>998
アンカーミスってねい？

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 81日 23時間 0分 8秒