ブロッキングI/Oについて

シリアルポートとGPIOポートを両方使用したプログラムを作成しました。read関数を使用した部分でブロッキングI/Oが原因となりGPIOポートが利用できなくなるという問題が起きました。
この問題自体はノンブロッキングI/Oの設定を行うことで解決できたのですが、以下の疑問が残りました。

・なぜI/O処理をブロックする必要があるのか
・ブロッキングI/OとノンブロッキングI/Oはどのように使い分けるのか
・ブロッキングI/Oという機能は何故出来たのか

I/Oポートの制限を行わない方がプログラムを作成しやすいと思うのですが、なぜread関数などは初期状態がブロッキングする状態になっているのでしょう。

No.1 ベストアンサー 回答者： SilverThaw 回答日時： 2009/06/30 16:29

>・なぜI/O処理をブロックする必要があるのか

「ノンブロッキング」はデータの受信(送信)完了を待たずに次の処理に移行することができる。
逆にいえば、受信データがそろわないうちに処理を行う為、データ欠損による問題が発生する場合があります。
もしくは、処理途中で次のデータを受信しバッファの上書きの可能性もあります。

>・ブロッキングI/OとノンブロッキングI/Oはどのように使い分けるのか
H/W特性、データ内容、それに付随する処理内容によって決定する。

>・ブロッキングI/Oという機能は何故出来たのか
前述の通り。
「なぜ」というよりも「なければ困る」から。

>I/Oポートの制限を行わない方がプログラムを作成しやすいと思うのですが、
「プログラムを作成しやすい」というのは間違いです。
それは「H/W特性」を理解せずにプログラムを作成していることに他なりません。
read「関数」はあくまでも「データを入力する」という抽象的な機能しか持っていません。
その先(入力I/F)が何かは理解できません。これを理解し適切に処理するのがプログラマーの役割です。

>なぜread関数などは初期状態がブロッキングする状態になっているのでしょう。
データを受信して処理を行っている間は、後発データによる上書きを禁止するため。

この回答へのお礼

ノンブロッキングにした場合データが受信途中のまま次の処理に移行してしまうということになるんですね。
H/W特性やデータ内容を考えた時にはブロッキングの方が良くなることもあるということを考えながらこれからプログラムを作っていきたいと思います。
ありがとうございました。

お礼日時：2009/07/01 08:10