非同期の完了待ちが根本的な問題の原因となっていることは多いです。
どんな問題か？それはあらゆる問題です。
再現性の低いバグ。もぐら叩き開発。
しかしながら、非同期完了待ち問題についての広いコンセンサスはありません。
場所によっては、「マルチスレッドプログラミングはクソ。すべてのプログラムはシングルスレッドに分解可能でかつ実装可能であり、そのほうが見通しも１００万倍良い。」などという石版に書かれた標語が壁に飾ってあったりするくらいです。
あるいはリアルタイムが分かってないやつがいるかぎり、このシステムはどうにもならない、というようなあきらめも多く耳にしますです。
偽装請負員のごみためまんとしては、非同期処理とは金のなる木であるという認識です。
閑話休題。
年に１回くらい不定期に指摘していますが、未だに同期と非同期の意味を取り違えて使っているのを耳にします。もうウンザリですがコンセンサスのために主張し続けます。
ソケットプログラマ向けの解説：同期処理、といったら、ブロッキング処理のことです。非同期処理といったら、ノンブロッキング処理のことです。
マルチタスキング向けの解説：タスクとタスクの同期というのは、排他制御のことです。 タスクとタスクが非同期、というような用例はNGです。
OOマニア向けの解説：同期オブジェクトと言ったときの、同期は同期処理のことです。ブロッキング・ノンブロッキングとは直接関係ありません。
COMポート向け解説：同期式は、クロックに同期していることを示します。あのRS232Cには、同期すべきクロックがありませんが、スタートビットから受け手がクロックを生成してそれに同期するので、調歩同期式と呼ばれるわけです。これは日本語であって、英語ではasync、つまり非同期と呼ばれるわけです。
同期は、排他制御のための手段であるわけです。目的：排他、手段：同期。ですが、同期のための実装というのがあるわけで、それを「同期を取るために」と表現すると、排他のための手段の手段という感じになります。その辺で、スコープの違う人が同じ問題を眺めるともうダメポなんです。
お分かりいただけますでしょうか。
実はこの手の話を書くたびに、「分裂症の人って怖いよね」とか「分かってないやつが分かってるフリして勝手なこと1T(イッテラ)」とかすき放題かかれるので、もういやんなのです。
しかし素人が考えるこの程度のことすら整理されずに議論が空論するのが世の常なのです。悲しい限りです。
さて本題です。
そんな中、胸がスカッとする記事を目にしました。
画期的な「非同期完了待ち」のフレームワーク（1/3） － ＠IT MONOist
このように複数の完了待ちAPIの細かな出し分けとは、結局のところユーザーランドでのポーリングと等価な行為です。X Window Systemを使わなくても、スレッドが周期的に起床されてしまうのです（ポーリングとはユーザーランドが無限にCPUを使い得るというナイーブな仮定に基づくナイーブなスタイルなので、それを採用した以上、CPUと貴重な電源を食い散らかされるのは自明である、ということもできます）。
非同期であるものをポーリングで待つということは、ぶつ切りの同期処理で非同期処理を真似ているに過ぎません。それにまつわるコンテキストスイッチのコストと、ポーリングの空振りの比率の高さとそのコストのトレードオフについての含蓄のある表現ですね。もちろん上手に実装して準最適化は可能ですが、せっかく用意されているフレームワークを使わないのはただの阿呆か自意識過剰ですよね。
とにかく、さすが、Ｋ・Ｋ・Ｋ。
先日も某官庁にてWindows版の桐の現役維持策が図られたと聞きます。良いものはいつまでも生き残るものです。
