前スレ
C++相談室 part155
https://mevius.5ch.net/test/read.cgi/tech/1616555235/
C++相談室 part156
レス数が1000を超えています。これ以上書き込みはできません。
1デフォルトの名無しさん
2021/05/19(水) 10:55:13.24ID:LZZifCH2993デフォルトの名無しさん
2021/08/08(日) 23:43:25.11ID:2XV4yDHI スレッドが実行中か確認したいってどんなときなのかな?
確認したところで次の瞬間には終了してる可能性あるわけじゃん
終了を待機したいならjoinすればいいし実行中をなんのために確認したいのかよくわからん
確認したところで次の瞬間には終了してる可能性あるわけじゃん
終了を待機したいならjoinすればいいし実行中をなんのために確認したいのかよくわからん
994デフォルトの名無しさん
2021/08/09(月) 00:16:27.81ID:bkD+cive 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の仲裁が必要じゃなくなる
> 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の仲裁が必要じゃなくなる
995デフォルトの名無しさん
2021/08/09(月) 00:22:59.44ID:bkD+cive あと(pthread_mutexのようなネイティブの)mutexはそういう理由で大抵の場合は最速のロック機構になっているので, 自分で作るなら普通にmutex使った方がいいというのは同意
素人(俺とか)の考えたロックフリーデータ構造とか大抵設計か実装かその両方でバグが入る
素人(俺とか)の考えたロックフリーデータ構造とか大抵設計か実装かその両方でバグが入る
996デフォルトの名無しさん
2021/08/09(月) 07:54:40.07ID:eF2Q2UUf >>989
mutexが遅くてイヤならatomicじゃね?
mutexが遅くてイヤならatomicじゃね?
997デフォルトの名無しさん
2021/08/09(月) 09:47:15.53ID:TRAo/ccI >スレッドが実行中か確認したいってどんなときなのかな?
排他制御付きのキューを自力実装するときまれによくある……
キューがあふれそうになったときpushする側(producer)を待たせる作りにした場合、
popする側(consumer)はデータをpop後、producerが待っていたらその待ちを解除、
待っていなかったら何もしないという判断が居るのでこのためのフラグ
(producer側にpushを継続する意思があるかどうか、またはpush待ち中かどうかを表すフラグ)が居る
producerよりconsumerがいつも速い見込みでキューがあふれない前提(キューが必要に応じていくらでも大きくなる)
だったりその他(待ち解除が条件変数ではなくキューイングされるイベントだったり)だと無くてもよいから
ぜってー必要か、というとビミョーだがあった方がすっきり効率的なコードとして書ける
排他制御付きのキューを自力実装するときまれによくある……
キューがあふれそうになったときpushする側(producer)を待たせる作りにした場合、
popする側(consumer)はデータをpop後、producerが待っていたらその待ちを解除、
待っていなかったら何もしないという判断が居るのでこのためのフラグ
(producer側にpushを継続する意思があるかどうか、またはpush待ち中かどうかを表すフラグ)が居る
producerよりconsumerがいつも速い見込みでキューがあふれない前提(キューが必要に応じていくらでも大きくなる)
だったりその他(待ち解除が条件変数ではなくキューイングされるイベントだったり)だと無くてもよいから
ぜってー必要か、というとビミョーだがあった方がすっきり効率的なコードとして書ける
998デフォルトの名無しさん
2021/08/09(月) 09:51:30.16ID:TRAo/ccI999デフォルトの名無しさん
2021/08/09(月) 09:55:16.95ID:TRAo/ccI となるようにインクリメントするカウンタの意味を仕向ける
1000デフォルトの名無しさん
2021/08/09(月) 09:55:21.66ID:eF2Q2UUf >>998
アンカーミスってねい?
アンカーミスってねい?
10011001
Over 1000Thread このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 81日 23時間 0分 8秒
新しいスレッドを立ててください。
life time: 81日 23時間 0分 8秒
レス数が1000を超えています。これ以上書き込みはできません。
