C++相談室 part156

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

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

**デフォルトの名無しさん** · 2021/08/01(日) 17:51:30.09

何で弱衝突耐性に確率が出てくるんだよ

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

ハッシュ関数への入力の時点で衝突してるんだから、MD5だのSHA1だのは関係無い

>>810の時点で指摘されているんだが、いつまでこの無意味な話を続けるつもり？

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

>>900
入力範囲のサイズ＞＞出力範囲のサイズである以上、
全部の入力を考えたら必ず衝突する＆入力範囲（一般に天文学的サイズ）の総当たりは一般遂行不能なので
確率評価するしかないからじゃゃわ；；

もちろん、特定の論理的操作で弱点をピンポイントで突けることがわかった場合は
ハッシュの衝突耐性の見積もりが確率ではなく論理的に下方修正されるが、そうなった時はそのハッシュが寿命を終えたとき、、、

ｶﾞﾁで基本がわかってない>>900、、、大丈夫なのか、、、

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

> ｶﾞﾁで基本がわかってない

弱衝突耐性とは何かがわかっておらず
正解を書いていながら正解として使えてないやつに
言われたかねえなｗ

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

>>895
入力バイト列の先頭64バイトを返す「ハッシュ関数」は一様だが衝突耐性は無い
入力バイト列のSHA-256にパディング32バイトを加えて返す「ハッシュ関数」は一様ではないがSHA-256と同レベルの衝突耐性を持つ

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

>>872 >>874
どう考えたら
> ハッシュにおける正常と異常の境界を聞いている
に対する回答
> そんなの設計仕様次第だろ。SHA1は仕様を満足できないから異常
への反論が
> 弱衝突耐性を破る方法が見つかったか否かが境界というのはおかしいだろ
> 未発見であることと存在しないと証明されていることは違う
になるんだよ。
『設計仕様を正常と異常の境界とすること』と『異常（脆弱性）の不存在証明の有無』は全く関係ない。
SHA1の例でいうと、衝突攻撃の研究によってSHA1の正常・異常の状態が『正常かどうか不明』→『異常』に変化しただけの話で、『境界』と『不存在証明の有無』は矛盾しない。
議論するなら『設計仕様を正常と異常の境界とすること』に対する問題点や矛盾を示せよ。論点ずらしなんかしないで。

あと、>>872は弱衝突耐性(原像計算困難性)云々言っているが、なんで弱衝突耐性？大本の議論（ID被り）からすりゃ強衝突耐性のほうが重要だし、SHA1で問題になっているのも衝突攻撃に対する脆弱性だろ。SHA1に対する原像攻撃って成功していたっけ？
もしかして>>872は弱衝突耐性と強衝突耐性の違いも知らないでハッシュを語っているのかね？ Wikipediaにすら解説が載っているのに。

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

ウィキを３時間読んできたのね、ご苦労さん
もっと簡単化した文章が書けるように消化してから書いてね
俺、ここでウィキとやりあうつもりはないから

# ちな、俺はウィキのとある記事の中の人

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

　　　　　ｶﾀｶﾀ
　　||￣ Λ＿Λ
　　||＿（Д`；　）　「なに？このスレ・・・」
　　＼⊂´　　　）
　　　　（　　┳'

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

>906
三時間……？なんのこと？　なんか幻が見えていない？
>905に反応するなんて、もしかして>906は>872 >874だったりするのかね。
弱衝突耐性を理解できていないアホとハッシュの話をしても仕方がないが……

> ちな、俺はウィキのとある記事の中の人
Wikipediaの記事を書いているなら『ウィキ』とかアホな言い方するなよ。
それとも文脈無視して本来の意味の『ウィキ』で使っているのかね。

用語をいい加減に使うヤツは議論や情報共有の邪魔になるゴミ。
Wikipediaで『ウィキ』ぐらい調べてから使えよ。

>907
いつもの楽しい5chのスレです。

**デフォルトの名無しさん** · 2021/08/02(月) 08:57:10.51

聞きかじったことをリピートしてるだけで
自分なりに熟れてないの見え見えだからｗ

くだらん言葉尻でもいいからと
あら探しに必死な姿は恥の上塗りなだけだぜ

**デフォルトの名無しさん** · 2021/08/02(月) 11:14:55.63

君もしかして天に唾するクンか？

**デフォルトの名無しさん** · 2021/08/02(月) 11:23:38.63

弱衝突耐性という用語を使いだしたのは俺だが
「SHA1は仕様を満足できない」と言い出したのはおまえさんだぜ

俺はただ正常と異常の境界は何かと聞いただけ
そこへ弱衝突耐性を意味する話をしだしたのがおまえさんだ
ここからそもそも頓珍漢なんだがｗ

**デフォルトの名無しさん** · 2021/08/02(月) 11:38:15.60

>911 >872 >874
どう考えたら
> ハッシュにおける正常と異常の境界を聞いている
に対する回答
> そんなの設計仕様次第だろ。SHA1は仕様を満足できないから異常
への反論
> 弱衝突耐性を破る方法が見つかったか否かが境界というのはおかしいだろ

の流れで

＞そこへ弱衝突耐性を意味する話をしだしたのがおまえさんだ

という話になるんですかねぇ。
弱衝突耐性の話を出してきた>872は俺じゃないよ。

**デフォルトの名無しさん** · 2021/08/02(月) 12:23:45.40

いーや弱衝突耐性の出してきたのは>>871だ
奴は弱衝突耐性という用語を知らなかったようだが
間違いなくその話をしている

**デフォルトの名無しさん** · 2021/08/02(月) 12:25:06.19

ハノンがコテ隠して発言してて草

**デフォルトの名無しさん** · 2021/08/02(月) 12:42:51.63

>>913
歴史改竄するなよ。
なんでSHA1の脆弱性の話をしているのに弱衝突耐性の話になるんだよ。

もしかしてSHA1の脆弱性が弱衝突耐性に関するものだと勘違いしている？
それなら一連の発言の辻褄が合ってくるけど、まさかね。

**デフォルトの名無しさん** · 2021/08/02(月) 12:45:20.48

>>915
ほうほうｗ
ではSHA1の脆弱性が何だと思ってるんだ、おまえさんは？

**デフォルトの名無しさん** · 2021/08/02(月) 12:56:24.24

>>916
お前は>>906でいちゃもんつけている>>905を読むという誠実さすら無いのか。

バカな上に傲慢とは救いようが無いな。

**デフォルトの名無しさん** · 2021/08/02(月) 13:05:07.60

何スレやねん
move論争の方がまだマシだったな

**デフォルトの名無しさん** · 2021/08/02(月) 13:28:50.14

>>917
やーい答えらんねえｗ
ブラフまで幼稚とはどこまでも無能なやつだな

**デフォルトの名無しさん** · 2021/08/02(月) 14:17:15.73

　　＿＿＿＿＿＿＿_
　　|　＿＿＿＿＿_ ／￣￣￣￣￣￣＼
　　| |　　　　　　　／ ⌒　　ー､　 :::::::::::U:＼
　　| |　　　　　　 /（ ○）}liil{（ ○）　 ::::::::::::::| 　　なにこのスレ・・・
　　| |　　　　　　.|U⌒（__人__） ⌒　　 ::::::U::::|
　　| |　　　　　　 |　　　|r┬-|　U...:::::::::::::::::::/
　　| |＿＿＿＿　ヽ　　｀⌒´.....:::::::::::::::::::::::<
　 └＿＿＿／￣￣　　　　　　:::::::::::::::::::::::::|
　　|＼　　　 |

**デフォルトの名無しさん** · 2021/08/02(月) 15:45:48.15

ケンカ成分入れたのはこいつ
>>866

**デフォルトの名無しさん** · 2021/08/02(月) 16:50:20.92

最初にSHA1の話を始めた >>859 が荒れた原因だよ
独りよがりで読解力がないことがたった二行で伝わってくる

**デフォルトの名無しさん** · 2021/08/02(月) 17:03:35.19

ダイジェスト長約48bit相当しかない5chのIDをなぜかダイジェスト長160bitのSHA1に関連付けて語りだしたアホがすべての原因

**デフォルトの名無しさん** · 2021/08/02(月) 17:07:16.03

宝くじ一等当選確率を1千万分の1とすると、log(10000000)/log(2) = 23.253496664... つまりダイジェスト長は約23bitに相当する

**デフォルトの名無しさん** · 2021/08/02(月) 18:28:05.17

>>919
あらら、幼児退行したか。
議論もレスバも意味ないな。相手にするだけ無駄か。
ロクに調べずに、SHA1の脆弱性の話で弱衝突耐性とか言い始める無能だからなぁ。

とりあえず>>919はコテハン付けとけ。NG設定するから。

**デフォルトの名無しさん** · 2021/08/02(月) 18:57:52.80

あわしろ氏は、そうは言ってなかったな。

**ハノン** ◆QZaw55cn4c · 2021/08/02(月) 19:53:00.83

>>914
わたしじゃないですよ！あとハノン呼ばわりは本意じゃないから止めて！

**デフォルトの名無しさん** · 2021/08/02(月) 21:26:49.50

名乗っておいて呼ぶなとは一体…

**デフォルトの名無しさん** · 2021/08/03(火) 00:20:17.34

質問です
クラス型の変数を関数内で宣言してreturnする関数があって、別の関数からクラス型の変数の宣言と同時にその関数呼び出したときに、moveコンストラクタをdeleteしてるとコンパイルエラーになるのでmoveしてると思いますが、moveコンストラクタを自前で作ってprintfしてても何も出力されないのはどうゆうことですか？

**デフォルトの名無しさん** · 2021/08/03(火) 00:45:04.37

それは近年話題沸騰中のNRVO・ムーヴ省略でございます

**デフォルトの名無しさん** · 2021/08/03(火) 00:47:12.42

move constructorをdeleteすると自動的にcopy constructorも
deleteされるからコンパイルエラーになるのでは

**デフォルトの名無しさん** · 2021/08/03(火) 07:24:04.62

>>922
SHA1とは言ったが脆弱性とは言ってない
まんまと思う壺にハマって地団駄踏んでももう遅いんだよｗ

**デフォルトの名無しさん** · 2021/08/03(火) 08:13:23.67

>>932
コテハン付けろよ。

**デフォルトの名無しさん** · 2021/08/03(火) 08:19:20.45

やだね
匿名掲示板をらしく使うのさ

**デフォルトの名無しさん** · 2021/08/03(火) 08:21:29.28

お、おう

**デフォルトの名無しさん** · 2021/08/03(火) 11:04:05.90

>>930
ムーヴ省略ではないでしょ

**デフォルトの名無しさん** · 2021/08/03(火) 11:10:04.38

>>936
寝ぼけてましたすんません
>>937が正しいですね

**デフォルトの名無しさん** · 2021/08/03(火) 11:10:55.96

>>937→>>931
もうだめだ

**デフォルトの名無しさん** · 2021/08/03(火) 12:43:15.32

>>938
オキロ

**デフォルトの名無しさん** · 2021/08/03(火) 13:37:49.45

>>931
初めて知りました。ありがとうございます
その線で試してみます

**デフォルトの名無しさん** · 2021/08/03(火) 22:48:49.67

>>929 の者です
何もしてないときはNRVO、
move constructorをdeleteしたときはcopy constructorが暗黙定義されずコンパイルエラー、
move constructorを自分で書いたときはcopy constructorが暗黙定義され呼ばれる
となっていたようです
NRVOという機能があることも知らず勉強になりました
ありがとうございました

**デフォルトの名無しさん** · 2021/08/03(火) 23:08:06.61

>>941
すみません、もう一回ちゃんと見てみたらcopy constructorは全く関係なかったです
move constructorがあればRVO/NRVOが働き、deleteすれば削除された関数を参照しようとしていますとなってコンパイルエラーでした

**デフォルトの名無しさん** · 2021/08/06(金) 00:25:17.82

begin と end ってどう実装すりゃ良いのか分からんのだが
イテレータの方で「beginイテレータ」と「endイテレータ」みたいなものを実装しておいて begin と end はそれを呼ぶだけにするのってアリ？

あるいは、イテレータの初期値が begin 相当の場所を指すようにしておいて、イテレータの方で + 演算子を実装しておいて、
begin は初期化されたイテレータを、end は初期化されたイテレータ+Nを返すようにするもの？
ただし N はそのクラスのサイズみたいなものとする

**デフォルトの名無しさん** · 2021/08/06(金) 03:50:58.62

>>943 具体的な懸念が無いなら好きに試してみろとしか言えないかな。

**デフォルトの名無しさん** · 2021/08/06(金) 07:46:08.96

>>943
特に詳しく無いんだけど（レベル低い話してたらごめんなさい）。

自分書いた時は、自分でこさえたコンテナクラス内にclass my_iterator を定義して、
必要な typedef (difference_typeなど)を行って（これやらんとアルゴリズムによっ
てはあれが無いとか文句言いよる）、あとは、いくつかの演算子を定義した。
イテレータの演算子は * ++ != あたりは定義したかな？足りなかったら追加の方向。

begin() end() は、my_iterator構築時にをポインタやインデックスなどの情報食わ
せて、そのオブジェクトを返す。
auto p = myobj.begin(), e = myobj.end();
while(p != e) { *p = ...; ++p; }

const に対応したり、後ろから反対向きにすすむ iterator とか、個別に定義して
いくとなんかかったるい。頑張って定義しても１回しかつかってねーよ的な。

自分は組み込みで書くことが多いんで、移植性の問題で標準ライブラリの利用も
ごく限定的なんで、劣化再発明でなんとかしないといけないことが多いから、
たまに必要になるんだけど。

**デフォルトの名無しさん** · 2021/08/06(金) 08:00:58.65

逆進反復子はstd::reverse_iteratorで合成できるやん

**デフォルトの名無しさん** · 2021/08/06(金) 11:23:00.02

演算子や反復子のオーバーロードはその性質上、オーバーロード箇所を見つけにくくなる副作用が大きくて使うの避けてるわ
ラムダ式は、たとえメモ帳で開いた場合でも視認性は落ちないからこの種の副作用はない

**デフォルトの名無しさん** · 2021/08/06(金) 11:28:33.23

反復子は仮引数を持たないから多重定義できない

**デフォルトの名無しさん** · 2021/08/06(金) 12:40:53.32

>>945
レベル低いっつーか聞かれてもない当たり前のことを長く言っている

**デフォルトの名無しさん** · 2021/08/06(金) 13:39:39.31

operator* != ++(前置)を持ってるオレオレイテレータとそれを返すbegin()とend()が揃ってれば
拡張for文で使えるから大抵はそれで十分

**デフォルトの名無しさん** · 2021/08/06(金) 13:45:20.78

iterator_traitsも使わんのか
最近の小わっぱどもわ

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/06(金) 14:06:55.11

イテレータのカテゴリ (ランダムアクセス、双方向、片方向) によるが、
イテレータとして求められる要件は (C++11 だと) 24.2 にまとめられている。
https://timsong-cpp.github.io/cppwp/n3337/iterator.requirements

requirements はあくまでも標準においてはこういう前提を置いているという話なんで、
標準ライブラリとの組み合わせを考えなくていいなら厳密に従う必要はない。
組み込み系とかではどうせ標準ライブラリのフルセットなんか提供されないってことも多いだろうし。

**デフォルトの名無しさん** · 2021/08/06(金) 14:25:41.28

>>943
上のやり方と下のやり方でどっちが良いか決めるなら、当然下のやり方だろう

**デフォルトの名無しさん** · 2021/08/06(金) 15:02:59.98

>>943,953
補足
前者はそもそも意味がよーわからん

**デフォルトの名無しさん** · 2021/08/06(金) 20:55:48.69

だれかSOLID原則わかりやすく教えて

**デフォルトの名無しさん** · 2021/08/06(金) 21:09:37.01

Dは重要

**デフォルトの名無しさん** · 2021/08/06(金) 21:15:50.18

依存性逆転…
メンヘラに逆に依存しろってこと？

**デフォルトの名無しさん** · 2021/08/07(土) 21:57:40.18

OSAL（Operating system abstraction layer）について教えてくだちい
正しいAPI仕様はどこ見たら良いの？
ぶっちゃけスレッドの生成とJOIN、クリティカルセクション、イベント通知手段、セマフォ、遅延（Sleep）
が使えれば良いぐらいのミニマルな要求なので自力実装しても良いが方言を増やしても仕方が無いし、

**デフォルトの名無しさん** · 2021/08/07(土) 22:19:39.31

std::threadつかうかpthread使えば。

**デフォルトの名無しさん** · 2021/08/07(土) 22:28:21.15

これじゃないの？知らんけど
ttps://github.com/nasa/cFS/blob/gh-pages/OSAL_Users_Guide.pdf

**デフォルトの名無しさん** · 2021/08/07(土) 22:38:16.24

お猿って読むのかな？

**デフォルトの名無しさん** · 2021/08/07(土) 23:51:20.36

>pthread
質問しておいてｱﾚですが確かにOSの抽象化はPOSIXじゃいかんのか、とは思いました
ただpthread関連は使いにくいすぐる……
Win32APIでpthreadの互換品を作る事態になったら何のために生きているのかわからなくなりそう……

**デフォルトの名無しさん** · 2021/08/07(土) 23:59:07.20

使いにくいって
学習しろよバカが

**デフォルトの名無しさん** · 2021/08/08(日) 03:38:56.69

RTOS向けのAPIらしいねOSAL
そういう用途で重要な要件を満たせるような仕様になってるのだろう知らんけど

**デフォルトの名無しさん** · 2021/08/08(日) 05:12:10.85

どちらかというとコードの動きが詠めずにコンパイルエラーに頼りまくるバカの方が大問題な気がする

**デフォルトの名無しさん** · 2021/08/08(日) 09:36:28.23

コードの動きを、詠む
風流だな

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

std::threadを使わない理由を説明してもらわんとアドバイスのしようがないね

**デフォルトの名無しさん** · 2021/08/08(日) 11:10:29.77

コードはアートだぞ?

**デフォルトの名無しさん** · 2021/08/08(日) 11:17:36.30

コードアートオンライン

**デフォルトの名無しさん** · 2021/08/08(日) 13:32:41.01

プラットフォームごとにスレッド関数がまちまちなことは大した問題じゃないんだが、スレッド同期を考えればstd名前空間のクラスを使うのが今後の最適解になるでしょ

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

コンパイラや標準ライブラリの製作者よりも俺の方が詳しいと確信できる時以外は素直にstdに甘えるべき

**デフォルトの名無しさん** · 2021/08/08(日) 15:36:10.77

int a[3] = {1, 2, 3};
for(auto&& b : a) { std::cout << b; }

この範囲for文の「&&」って何者なの？
参照？
autoもautoで、autoはC++11で廃止になったって聞いてたんだけど・・・

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/08(日) 15:50:15.52

>>972
auto は C から引き継いで C++ にも以前からあったキーワードだけれど、
誰も使ってなかったから元の意味を廃止してあらたな意味で使われるようになった。
廃止されたのは auto の以前の使い方であってキーワード自体は廃止されてない。

**デフォルトの名無しさん** · 2021/08/08(日) 16:04:41.80

値の参照値変数を伴ない値参照とでもいうべきか

**デフォルトの名無しさん** · 2021/08/08(日) 16:06:14.93

釣りじゃないなら、とりあえず右辺値参照でググって一通り読んでこい
ここで全部説明してると長すぎる

**デフォルトの名無しさん** · 2021/08/08(日) 16:07:11.93

forループとかココらへんはコンパイラの最適化によっては&参照とあんま変わらんよな

**デフォルトの名無しさん** · 2021/08/08(日) 16:15:05.55

auto && に関しては右辺値参照とは限らないというのもまたややこしい

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/08(日) 16:16:14.37

>>972
&& は普通は右辺値参照を意味するが、一部の状況では万能参照になる。
(言語仕様上は万能参照とは呼ばれないが通例としてそう呼ぶことが多い。)
初期化子によって左辺値参照か右辺値参照かを自動的に選択するので、
よく理解できてないなら範囲for文をつかうときは && にしておけと入門者に勧める解説はよく見る。
実際、その状況では auto& と書いても結果は変わらない。

**デフォルトの名無しさん** · 2021/08/08(日) 16:53:04.10

>>973
>>978
ありがとう・・・！
メモっとく

**はちみつ餃子** ◆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

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