Win32API質問箱 Build124

**デフォルトの名無しさん** · 2017/11/11(土) 19:23:00.69

Win32APIについての質問はこちらへどうぞ。

■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
　英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで

■過去スレ
Win32API質問箱 Build123
http://mevius.2ch.net/test/read.cgi/tech/1475897582/
Win32API質問箱 Build122
http://echo.2ch.net/test/read.cgi/tech/1451988219/
Win32API質問箱 Build121
http://echo.2ch.net/test/read.cgi/tech/1438695290/
Win32API質問箱 Build120
http://echo.2ch.net/test/read.cgi/tech/1428570962/

■関連スレ
Visual Studio 2017 Part4
http://mevius.2ch.net/test/read.cgi/tech/1509244956/
【C++】 DirectX初心者質問ｽﾚ Part40 【C】
http://mevius.2ch.net/test/read.cgi/tech/1474782237/

**デフォルトの名無しさん** · 2019/02/22(金) 21:44:37.57

spurious wakeupがある→正しい
使うな→よりより代替手段がなければ使うしかない

代替手段があるかどうかは環境によるから先輩ちゃんに聞く

**デフォルトの名無しさん** · 2019/02/22(金) 22:18:48.32

https://docs.microsoft.com/en-us/windows/desktop/sync/condition-variables
条件変数のAPIではspurious wakeupsに言及がある、ただしWaitForSingleObjectなどでは言及が見つからなかった

https://stackoverflow.com/questions/38757420/is-waiting-for-an-event-subject-to-spurious-wakeups
出典不明だがWaitForSingleObjectはspurious wakeupが起こらないとある
WaitForMultipleObjectsExでは、bAlertableにTRUEを渡せばspurious wakeupが起こりうるらしい

先輩の情報源を知りたい

**デフォルトの名無しさん** · 2019/02/22(金) 22:23:38.90

同期オブジェクトが非シグナル状態でWaitFor系関数から勝手に戻ってくることはないと断言できる
仕掛けるオブジェクトに依ると思う

**デフォルトの名無しさん** · 2019/02/22(金) 22:27:18.85

ただし単に寝ていたスレッドが起きるという現象自体は外部のCPU負荷調節アプリとかでResumeTheradを発行することで簡単に再現できる

**デフォルトの名無しさん** · 2019/02/22(金) 23:11:25.13

魔王も勇者が入って来ただけで起きるしな

**デフォルトの名無しさん** · 2019/02/22(金) 23:26:13.44

そもそも何をWaitFor系関数で待つのかってのも大きい。自作Signalオブジェクトなら問題起きないでしょ。

**デフォルトの名無しさん** · 2019/02/23(土) 07:23:17.25

>>927
以前、2つのプロセス間で、WaitForSingleObject() を CreateEvent(), SetEvent() 系
の HANDLE で実験してみたけど、バグ的な現象は起きず、至って正常に動作し、
2つのプロセスで、お互いに、SetEvent() したり、WaitForSingleObject() で
相手を待ったりして、ハンドシェイク的な振る舞いが思ったとおりに出来ることが
確認できた。

速度も、SetEvent() した事が相手に届くまで、確か、1(μs)前後だったので、
十分速いと結論付けた。

**デフォルトの名無しさん** · 2019/02/23(土) 08:40:48.30

C++標準のwait系にはあるからいちいち確認するしなきゃいけないから面倒だよな
しかも、イベントだけ使いたいのにいちいちmutexをよういしなきゃいけないし・・・

**デフォルトの名無しさん** · 2019/02/23(土) 11:36:21.35

都市伝説かも知れんが
そもそもいつ発生するか判らない発生しないかも判らない現象を
ちょっとテスト書いてみて大丈夫（キリつ

**デフォルトの名無しさん** · 2019/02/23(土) 11:54:16.12

条件変数ならともかく、Eventなんかはspuriousで起こされても確かめようがないんじゃないのかな。

**デフォルトの名無しさん** · 2019/02/23(土) 16:03:56.92

同期機能は同期機能としてそのまま利用しつつ、最低限の安全性や整合性については別途確認すべきなのでは。

**デフォルトの名無しさん** · 2019/02/23(土) 18:44:58.70

WaitForSingleObject() には、MSDN の仕様書に書かれていないような意味においての
バグ的な spurious wakeup は起きないと思う。

なお、実験する限り問題ないが、絶対ないかどうかは誰にも分からない。

**デフォルトの名無しさん** · 2019/02/23(土) 18:57:16.07

c++標準ライブラリには堂々と書かれてるな
Windowsだとc++標準ライブラリを使う理由がないな

**デフォルトの名無しさん** · 2019/02/23(土) 19:07:25.29

同期オブジェクトは重要。
仕様書に何も書いてないのに、もし、spurious wakeup が起きるとしたらバグ。

なお、C++ の STL ライブラリは馬鹿が作ったと思ってる。
昔ながらの C の標準ライブラリは良い出来だが、それと混同しないほうがいい。

**デフォルトの名無しさん** · 2019/02/23(土) 20:04:03.30

C++のSTLとCライブラリでは機能が似ているところはない気がするけど？
念のため言っとくとiostreamはSTLじゃないよ。

**デフォルトの名無しさん** · 2019/02/23(土) 20:24:45.58

つーかspurious wakeupなんて存在を許してる時点で作ったそいつらはアホじゃないの
そいつらのリテラシーどうなっとんのか疑うレベル

**デフォルトの名無しさん** · 2019/02/23(土) 20:32:05.22

汎用性のためにファイルロックを使った排他処理で実装するとそうなってしまうんじゃないの。知らんけど。

**デフォルトの名無しさん** · 2019/02/23(土) 22:14:41.32

厳密にspurious wakeupを許さない実装は大変でパフォーマンス的にも不利だから。
というか、spurious wakeupを許すとすごく有利だというのが後から発見されたんじゃなかったかな。

**デフォルトの名無しさん** · 2019/02/24(日) 02:55:03.61

っていうか、win環境ならC++標準ライブラリよりWaitFor～を使ったほうがいいだろ
std::unique_lockなんで馬鹿みたいに遅いしｗ

**デフォルトの名無しさん** · 2019/02/24(日) 04:17:10.21

>>937
WaitForSingleObject()ってエラー返すことがあるよね？仕様上では。
要はちゃんとエラーハンドリングしろって話だけどさｗ

**デフォルトの名無しさん** · 2019/02/24(日) 08:23:50.21

>>943
プログラムには優先順位があって、まず、正しく動作する事が一番重要。
その次に来るのが、使いやすさか、または、速度。どちらが優先されるかは
設計思想や哲学による。その次にプログラムのサイズ。

いくら速度が速くても、やるべきことが正しく行われないならプログラムとしては
失格なんだ。

**デフォルトの名無しさん** · 2019/02/24(日) 08:36:16.85

「sprious wakeupもありえる」というのを「正しい動作」と定義したんだから何の問題もない。

**デフォルトの名無しさん** · 2019/02/24(日) 08:48:33.63

それだと、使う側のプログラムが長くなるだけなので、設計思想に問題を感じる。
ライブラリ設計者の経験不足かもしれない。
速くなるといっても結局、使う側でループの中で判定して条件に合わないなら、
また繰り返し、wait するのなら、ライブラリ側でそういう風にできなかったの
だろうか。

**デフォルトの名無しさん** · 2019/02/24(日) 09:42:01.89

深く考えてないけど、以下のようにしてしまえば、速度が速いまま、
spurious wakeup が絶対に起きない wait 関数を作れるんじゃないかと
思うんだけど、どうなんだろう。

Xxxx LapperWait(Yyyy y, Zzzz z) {
　　for (;;) {
　　　raw_wait(y, z);　　// spurious wakeup 有り
　　　if ( IsCond(y, z) ) {　　// 厳密な条件チェック
　　　　　return x;
　　　}
　　}
}

**デフォルトの名無しさん** · 2019/02/24(日) 10:03:24.37

>>949
深く考えてから書き込みましょう。
ぼくのかんがえたさいきょうの同期実装についてはスレ違いなので、よそでやってください。

**デフォルトの名無しさん** · 2019/02/24(日) 14:42:49.21

LoopyWaitでいいよもう

**デフォルトの名無しさん** · 2019/02/24(日) 15:26:11.06

「sprious wakeupもありえる」のはいいが、
どのAPIも使うたびにいちいち関数仕様確認するのは面倒だな

つーか関数の説明には書いてないので仕様とは言えないと思うんだが・・・初見殺し？

**デフォルトの名無しさん** · 2019/02/24(日) 15:39:02.49

>>952
初めて使うAPIでしかも同期処理なんて複雑なものは仕様を調べて使うのが当然のことだと思うぞ。

**デフォルトの名無しさん** · 2019/02/24(日) 16:04:30.12

>>949
　　　raw_wait(y, z);　　// spurious wakeup 有り
と
　　　if ( IsCond(y, z) ) {　　// 厳密な条件チェック
の間で条件が変わったらどうするの？

**デフォルトの名無しさん** · 2019/02/24(日) 16:07:02.11

>>954
え、それはプログラミングの仕方の問題じゃないの？
元々、マルチスレッドプログラムは難しいんだけど、それと今回の
問題は別なのでは。

**デフォルトの名無しさん** · 2019/02/24(日) 16:08:45.84

>>955
どうやってプログラムで回避するの？
回避できないんだったら「絶対に起きない」なんて言えないだろ。
こんなレベルで排他処理語られても...

**デフォルトの名無しさん** · 2019/02/24(日) 16:14:47.34

>>956
もともと、排他処理用のAPIは、そういう「変な問題が起きない」ように用意されて
いるんだよ。「Atomic」アクセス、などと言われていて、「途中に」とか
中途半端な状態が起きない作りにしてある。それは割り込み発生を好きにOFFに
できるところのシステム側(OS)でしかできない。

**デフォルトの名無しさん** · 2019/02/24(日) 16:16:16.11

なぜかIDが勝手に変わったが、949=955=957だ。

**デフォルトの名無しさん** · 2019/02/24(日) 16:17:26.62

同期オブジェクトの正確性ではなく、ユーザ定義データの保護こそが大切。目的を見失わないように。

**デフォルトの名無しさん** · 2019/02/24(日) 16:18:28.55

ちなみにオイラは、32BITマルチタスクOSを作った経験がある。

**デフォルトの名無しさん** · 2019/02/24(日) 16:24:01.17

>>949
シングルスレッド脳だとそういう発想になる

**デフォルトの名無しさん** · 2019/02/24(日) 16:34:48.90

たまにかかってくる間違い電話がいやだから電話は無能。そんな感じ。

**デフォルトの名無しさん** · 2019/02/24(日) 16:36:35.10

Atomicを語るならID変わらないようにしないと恥ずかしいな

**デフォルトの名無しさん** · 2019/02/24(日) 16:41:49.67

IDが変わる理由は知らん。多分、5chのシステム上の問題だと思う。

**デフォルトの名無しさん** · 2019/02/24(日) 16:43:05.47

沢山の人で賑わっているように見せるためかな。人寄せと広告料金関連で。

**デフォルトの名無しさん** · 2019/02/24(日) 16:46:55.09

コールバック形式のAPIを使うプログラマはその呼び出しタイミングをAPI側に委ねている。
何がいいたいかというと、要するにあきらめろということだ。

**デフォルトの名無しさん** · 2019/02/24(日) 17:53:55.79

>>957
それが起きるからどうするという話で、
あんたが糞の役のも立たないコードを出したんじゃん。
つまり>>954はクソだったと認めるということ？

**デフォルトの名無しさん** · 2019/02/24(日) 18:01:12.16

>>697
多分、あのコードで問題ないはずだ。
ちなみに、オイラは現実社会では天才と言われているよ。

**デフォルトの名無しさん** · 2019/02/24(日) 18:31:20.56

車のバンパーは本来、ボディを保護するためにある。
そのバンパーに傷がついたりへこんだりすることを病的に嫌悪している状態。
お大事に。

**デフォルトの名無しさん** · 2019/02/24(日) 18:39:12.54

もしそのraw_wait()がP命令だとしたらその結果がspuriousのときはV命令で状態を戻さなきゃならんと思うが。
ただどっちにしてもそのIsCond()はライブラリ側では構成しようがないけどな。

あと、やっぱりspurious wakeupって条件変数特有のものじゃなかったかな。
なんかそのへんで話がずれている気がする。

**デフォルトの名無しさん** · 2019/02/24(日) 18:54:16.69

>>970
どういう状況を考えてるのか前提が分からないし、だから
「深く考えてない」
という事になってしまうのだけども。少なくとも、Win32のWaitForSingleObject()
では特に問題は起きない。

**デフォルトの名無しさん** · 2019/02/24(日) 18:58:07.16

つ MsgWaitForMultipleObjectEx

**デフォルトの名無しさん** · 2019/02/24(日) 19:23:32.11

>>972
GetMessage相当が入ってるだけで基本WaitForと同じ動作だが何か？