質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.92%

WPF シリアルポート 入力待ちはループ?イベント?

解決済

回答 1

投稿

  • 評価
  • クリップ 1
  • VIEW 9,006

ElecDove

score 257

いつもお世話になっております。

WPFアプリの作成で、SerialPortを使っております。

相手機器からの返信を待つ際、
別スレッドで

while(SerialPort.readLine() != "ok");
//okがきた後の処理


という風に、okがくるまでwhileで待ち続けるか、
Recievedイベントでokかどうかを判断するのはどちらがよいでしょうか。

マイコンの場合は、ほかにすべき処理がなければループで延々と待ち続けることはよくあるように思いますが、Windowsアプリでは避けたほうがいいのでしょうか

何もしないwhileループは、CPUをどのくらい食うのか、とかがわかりません

また、シリアルポートに限らず、イベントというのは絶対的に信頼していいものなのでしょうか
何かの拍子に、okがきたにもかかわらず取りこぼしてしまうと、永遠に処理がとまりますし・・・(タイムアウトを設定するとかは別問題?)

人間がボタンを押したり、という場合であれば、
「押したのに処理がされない」場合はもう一度ボタンを押す、なんてことができますが・・・。

よろしくお願いいたします。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 1

checkベストアンサー

+1

こんにちは。

どちらがよいでしょうか。

ケースバイケースです。

基本的にイベント待ちする方法はポーリング、もしくは、イベント通知を待つのどちらかです。
前者はデッドロックを避けやすいですが、ポーリング間隔を短くするとCPUを無駄に消費しますし、長くすると応答性能が劣化します。
後者はCPU消費を最小限で応答性能を最大化できますが、デッドロックしないよう注意深い設計が必要です。(設計の難易度は高いです。)
ちなみにReadLine自体がイベント通知によって実装されていますので、while文に入れたとしてもそれはポーリングではありません。イベント通知による実装となります。

そして、具体的な実装方法として、スレッドを使って同期的に待つ方法とイベント通知でコールバックさせて非同期に待つ方法の2種類に別れます。前者はシーケンスを記述しやすいですが排他制御の問題が出やすく難易度が高いです。後者はシーケンス制御しようとするとコールバック地獄と呼ばれる地獄に陥りやすいです。

単純にこれらの組合せで4種類のイベント待ち方式が考えられます。
Windowsアプリの場合もこの4種類全てが考えられます。

ポーリングは性能が問題にならない場面に限った方がよいだろうと思います。
今は結構技術が進んでいるので、多くの場合自然にイベント通知方式で実装することになりますし。

「A要求→OK待ち → B要求→OK待ち → C要求→OK待ち → ・・・」のようなシーケンス的に待ちが発生する場合はスレッドを使った方が生産性は上がりやすいです。ただし、排他制御するスキルが必要になります。
「要求→OK待ち」で処理が完了するような時はコールバックによる非同期処理の方が排他制御の問題がでないので安心です。
C#はasync/awaitと言う新しい非同期処理方式があります。比較的お手軽に前者を実装できます。
でも、スレッドを使うと言う事実は同じですので排他制御についはて注意が必要です。

シリアルポートに限らず、イベントというのは絶対的に信頼していいものなのでしょうか 

そのシステム次第です。
イベント・システムを取りこぼしがないよう設計し、適切に実装されていれば取りこぼしはないでしょう。
しかし、そうではない場合は取りこぼしは発生します。Windowsでマウス・ボタンが押されたままになった経験はないでしょうか? これはWM_LBUTTONUP関連イベントの取りこぼしと思われます。(どの層で取りこぼしているのか知りませんが、Windows 10になってから酷くなった気がします。)

ボタンは取りこぼしが発生しやすいような気がします。連打されることを考えると寧ろある程度は取りこぼした方が却って良かったりします。
通信は取りこぼし自体は発生しないよう設計されているケースがほとんどと思いますが、ノイズ等によるデータ破壊を考慮し、タイムアウトなどの対策を入れるのが普通です。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/05 18:26

    回答ありがとうございます
    >>ちなみにReadLine自体がイベント通知によって実装されていますので、
    あ、そうだったのですね
    ReadLineを呼んだ時点で、受信バッファにあるデータが読まれるものと思っておりましたが違うのですね

    >ポーリングは性能が問題にならない場面に限った方がよいだろうと思います。
    >今は結構技術が進んでいるので、多くの場合自然にイベント通知方式で実装することになりますし。
    基本は、イベントで実装して、避けられない問題があった場合にポーリングを検討する、という漢字でしょうか


    そういえば、マウスやキーボードなんかは取りこぼすことがありますね
    たまにあれっってことが確かにあります

    そういえば、今回のシステムですが、okを検地できず、処理がとまってしまうと相当ヤバイ(物理的に)事が起きるので、相手機器のほうで対策したほうがよさそうです
    Winアプリ側と、相手側(マイコン )両方でタイムアウト対策は入れたいと思います


    ありがとうございました

    キャンセル

  • 2017/05/05 18:58

    > ReadLineを呼んだ時点で、受信バッファにあるデータが読まれるものと思っておりましたが違うのですね

    一行分のデータが既に入っていればそれが読まれます。
    そうでない時は1行分のデータが受信できるまで待ちます。
    その際、ポーリングではなくイベント通知方式で待ちます。

    > 処理がとまってしまうと相当ヤバイ

    であれば、通信のエラー・リカバリ処理はよく検討された方が良いです。
    パケットの同期やエラー・チェック、リトライ処理が必要になります。特にパケット同期(バケット先頭の検出)は意外に苦労します。
    シリアルの場合、ベーシック手順がメジャーですので参考にされると良いかも知れません。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.92%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る