WindowsMessage(ウィンドウメッセージ）の処理速度は？

VC++.NETでWindowsフォームアプリを作っていて、WindowMessageを使おうと思っているのですが質問させてください.

簡単にいえば、WindowsMessageの追従性というか、処理速度が知りたいのです.（以下の説明で、受信側、送信側は1回目の送受信において定義しています。CUI＝受信側、GUI＝送信側と考えてもらって構いません）

内容をわかりやすくするために例をあげて説明します。
●メッセージ受信側のプログラム内容(CUIと仮定)
WindowMessageで受け取った1～9の数字を利用した（任意の）プログラム。（いろいろと計算を行い）計算結果を一度コンソールに出力、そしてWindowMessageを利用してその内容をGUI側に返す。

●メッセージ送信側のプログラム内容（GUIと仮定）
Timerオブジェクトを利用して間隔1msec（最小）で(たとえば1～9の乱数を生成して）WindowMessageを送信する。
CUI側から帰ってきた数字は次の乱数生成時のseedに使う。


質問1
受信側のプログラムが（例えば受け取った数字をコンソールに表示する程度の）軽い内容だったとして、「コンソール出力」という処理はきっちり1msecはいかないにしても数msec単位で処理されるのか？（つまり、WindowMessageの処理の限界速度？が知りたい）

質問2
現状だと「GUI側から極めて短い間隔でどんどんWindowMessageが送られる」という状態になっていると思います。
WindowMessageの処理についてまだあまり勉強が進んでいないのでわからないのですが、この状態において、1発目のWindowMessageを処理している間に次のWindowMessageが来た場合、CUI側でどのような処理が行われるのでしょうか。

質問3
要は処理をGUI→CUI→GUI→CUI→GUIという順番で逐次処理させたいのですが、結局その目的に対して、WindowMessageは（一応）有効な手段なのか？


以上、一部分かりにくい表現があるかもしれませんが、回答のほどよろしくお願いします。

No.2 回答者： jmh 回答日時： 2009/11/10 20:31

質問1、たぶん、いいえ。

タイマーを１ｍ秒に設定しても、実際には１５ｍ秒とかになっちゃうみたい。「VB.NETのタイマー精度を測る」人が google で検索すると見つかります。こういうのはハードウェアによるかもしれません。
質問2、いいえ。あなたのデザインではＧＵＩは次の種を受け取ってないので（ＣＵＩからの返答なしに）、次を送信することがありえません。
質問3、はい、一応。送信（Ｓｅｎｄ）は同期だと思います。でも、タイマーはキューかもしれないので溜まっちゃうのかもしれません。

No.1 回答者： zwi 回答日時： 2009/11/09 22:21

質問1

まず、Windowsのタスクの切り替えの仕組みを理解してください。
http://itpro.nikkeibp.co.jp/article/COLUMN/20070 …
メッセージを送ったからといって通信先のタスクがすぐアクティブになる補償はなにもありません。
数msかも知れませんし、数十ms後かもしれません。あるいは、200ms後かも知れないです。

質問2
メッセージキューに溜まって行くだけです。
>CUI側でどのような処理が行われるのでしょうか。
どんなプログラムになっているか分かりませんが、GetMessageとかしているなら、１つづつメッセージを取り出して処理するだけです。

質問3
お互いにメッセージを待つなら、GUI→CUI→GUI→CUI→GUIと実行されますが、どちらかが待たない場合には、GUI→GUI→GUI→GUI→GUI→CUI→CUI→CUI→CUIとなったりします。
ただ、お互いに同期を待つ処理は非効率的なので、普通はそうならないように設計します。一回のやり取りに０．５秒掛かってもWindowsＯＳの仕様上は仕方のないことです。