戦国IT - 情報処理技術者試験の過去問対策サイト
ブログお知らせお問い合わせ料金プラン

応用情報技術者 2010年 秋期 午後 問07

携帯電話への録音機能追加に関する次の記述を読んで、設問1～3に答えよ。

　 　A社は携帯電話メーカーである。携帯電話をボイスレコーダとして使用できるよう、録音機能を追加することになった。
〔録音機能、及び関連するタスク、デバイス、メモリの関係〕 　録音機能はほかの機能と排他的に動作する。録音された音声データは、携帯電話の不揮発性メモリに保存して、再生及び外部メディアへの取出しができる。また、録音中に録音時間及び音声データのメモリ残量（以下、録音詳細情報という）をLCDに表示する。 　録音機能に関連するタスク、デバイス及びメモリの関係を図1に示す。
応用情報技術者試験（平成22年度 秋期 午後 問07 図01）
・オーディオデバイスは、マイクから入力された音声のアナログ信号をサンプリングし、PCM符号に変換して、録音データとしてサンプリング専用RAMに一時的に格納する。 ・録音データの音質は、音楽CD並み（サンプリング周波数44.1kHz、量子化ビット数16ビット、チャネル数2ch）とする。 ・1秒間の録音データを1ブロックとして格納する、1ブロック当たりのサイズはakバイトである。 ・オーディオデバイスは、1秒間の録音データを格納した後、割込みを発生し、録音タスクにメッセージを送信する。
〔ソフトウェア構成〕 　録音機能は、UIタスク及び録音タスクで構成され、タスク間の通信にはメッセージを使用する。各タスクの説明を表に示す。
応用情報技術者試験（平成22年度 秋期 午後 問07 表01）
〔不揮発性メモリの構成〕 　携帯電話の不揮発性メモリの構成を図2に示す。不揮発性メモリは、利用者設定領域と音声データ領域に分けられる。利用者設定領域には、携帯電話の着信音などの設定情報が格納されている。録音機能を追加するために、音声データのメモリ残量を追加する。一方、音声データ領域には音声データ及び録音時間を格納する。 　これらの領域はUIタスク及び録音タスクからアクセスされるので、利用者設定領域セマフォ及び音声データ領域セマフォの二つのバイナリセマフォによって、排他制御を行う必要がある。
応用情報技術者試験（平成22年度 秋期 午後 問07 図02）
〔録音機能の検証〕 　録音機能を実現するために、UIタスクでの録音詳細情報表示処理を図3のように、録音タスクでのエンコード処理を図4のようにそれぞれ設計した。録音タスクからUIタスクにメッセージを送信するタイミングについて、次の二つの場合を設定して実機で検証した。 　・図4中の(ア)で、録音タスクからUIタスクにメッセージを送信した場合 　　UIタスク及び録音タスクがともに動作しなくなった。 　・図4中の(イ)で、録音タスクからUIタスクにメッセージを送信した場合 　　録音タスクはb状態となり、UIタスクはc状態となった。 　次に、UIタスクはdセマフォを取得できず、e状態となった。
応用情報技術者試験（平成22年度 秋期 午後 問07 図03、04）

設問1：サンプリング専用RAMについて、(1)、(2)に答えよ。

（1）本文中のaに入れる適切な数値を答えよ。答えは、小数第2位を四捨五入して小数第1位まで求めよ。ただし、1kバイト=1,000バイトとする。

模範解答

a：176.4

解説

解答の論理構成

  1. 条件整理
    • 録音データの音質は【問題文】にあるとおり
      「音楽CD並み（サンプリング周波数44.1kHz、量子化ビット数16ビット、チャネル数2ch）」
    • また、「1秒間の録音データを1ブロックとして格納する」と明記されています。
  2. 1秒当たりのビット数を計算
    • 1サンプル＝「16ビット」
    • 1秒間のサンプル数＝「44.1kHz」＝44,100サンプル
    • チャネル数＝「2ch」
      よって
  3. バイト換算
    • 8ビット＝1バイトなので
  4. kバイト換算
    • 本問では「1kバイト=1,000バイト」と指示されています。
  5. 小数第2位を四捨五入して小数第1位まで求める
    • 既に「176.4」で小数第2位は存在しないため、そのまま「176.4」
したがって、aに入る数値は 176.4 です。

誤りやすいポイント

  • 1kバイトを 1,024 バイトで換算してしまい、値を「172.3kB」程度にずらしてしまう。
  • 8ビット換算を忘れ、ビット数をそのままキロ単位で回答してしまう。
  • チャネル数「2ch」を乗算し忘れ、モノラル換算で計算してしまう。

FAQ

Q: サンプリング周波数が「44.1kHz」ですが、キロの部分を1,024倍する必要はありますか？
A: いいえ。本問ではデータ量換算だけに 1,000 を用いる指示があるため、周波数についてはそのまま「44,100」として計算します。
Q: 小数第1位まで求める指示ですが、計算結果がちょうど「176.4」の場合も四捨五入は必要ですか？
A: 必要ありません。既に小数第2位以下が 0 なので、そのまま「176.4」で良いです。
Q: チャネル数が変わるとブロックサイズの式はどうなりますか？
A: 基本式は

です。チャネル数が 1 ならそのまま 1 を掛けて計算します。
関連キーワード: サンプリング周波数、量子化ビット数、PCM, ステレオ、データサイズ

設問1：サンプリング専用RAMについて、(1)、(2)に答えよ。

（2）録音タスクが連続してエンコードするには、最低何ブロック以上のサンプリング専用RAMが必要か。必要なブロック数を答えよ。

模範解答

2

解説

解答の論理構成

  1. 音声は 1 秒単位で取り込まれる
    引用：
    「・1秒間の録音データを1ブロックとして格納する」
    ⇒ サンプリング専用RAMに“1ブロック＝1秒分”が蓄えられる。
  2. 取り込み完了後に割込みが発生し、録音タスクが処理を開始
    引用：
    「・オーディオデバイスは、1秒間の録音データを格納した後、割込みを発生し、録音タスクにメッセージを送信する。」
    ⇒ 割込みごとに録音タスクがエンコード処理へ移る。
  3. エンコードは次の割込みまでに終了させる必要がある
    引用：
    「エンコードは、次のオーディオデバイスの割込み発生までに完了する。」
    ⇒ エンコード中にもオーディオデバイスは次の 1 秒分を取り込み続ける。
  4. バッファの同時使用を考える
    ・オーディオデバイスが現在取り込み中の“次のブロック”
    ・録音タスクがエンコード中の“前のブロック”
    上記 2 つを同時に保持できれば連続運転が切れ目なく行える。
  5. 結論
    並行して扱うブロックは「前の1 ブロック＋次の1 ブロック」＝2 ブロック。
    よって、最低必要数は 2 ブロック となる。

誤りやすいポイント

  • 「エンコードが1 秒以内に終わるなら1 ブロックでよい」と早合点する
    → その1 秒の間にオーディオデバイスは次のデータを書き込むため、書込み先が重複してしまう。
  • 割込み周期とエンコード処理時間の関係を見落とす
    → “次の割込み”までに終わる条件は、バッファ数を減らしてよい根拠にはならない。
  • “エンコード後に保存”の工程を忘れ、書込み先が塞がる時間を軽視する。

FAQ

Q: エンコードがさらに高速なら1 ブロックでも動きますか？
A: オーディオデバイスはハードウェア的に連続サンプリングを行うため、処理の速さに関係なく同時に2 箇所を確保するダブルバッファ構成が基本です。
Q: 3 ブロックにしてはいけないのでしょうか？
A: 3 ブロック以上でも問題ありませんが「最低」数を問われているため、最小で競合を防げる2 ブロックが解答になります。
Q: 割込みが遅延した場合でも2 ブロックで足りますか？
A: 遅延で取り込みが止まるわけではないので、遅延時間が1 秒を超えると不足する可能性があります。しかし問題設定では「次の割込み発生までに完了する」と明示されており、その前提で2 ブロックとします。
関連キーワード: 割込み処理、ダブルバッファ、バッファリング、排他制御、サンプリング

設問2：

図4中の(ア)で、録音タスクからUIタスクにメッセージを送信した場合、UIタスク及び録音タスクがともに動作しなくなった原因を30字以内で述べよ。

模範解答

「二つのタスクで2種類のセマフォ取得順序が逆だから」 または 「デッドロックが発生したから」

解説

解答の論理構成

  1. 問題文は、二つのタスクが同じ二つのバイナリセマフォを使用すると明示しています。
    引用：「利用者設定領域セマフォ及び音声データ領域セマフォの二つのバイナリセマフォによって、排他制御を行う必要がある。」
  2. UIタスクの処理順序は、 引用：「利用者設定領域セマフォを取得」→「音声データ領域セマフォを取得」
    の順でセマフォを取得します。
  3. 録音タスクのエンコード処理では、 引用：「音声データ領域セマフォを取得」→「利用者設定領域セマフォを取得」
    の順でセマフォを取得します。
  4. 異なる順序で同じ二つの資源をロックする設計は、クラシカルなデッドロック発生条件（相互排他・保持待ち・不可奪・循環待ち）のうち「循環待ち」を満たします。
  5. したがって、図4中の(ア)でメッセージ送信を挿入すると両タスクが互いのセマフォを保持したまま相手の解放を待ち、「UIタスク及び録音タスクがともに動作しなく」なる、すなわちデッドロックが発生します。
    結論として模範解答の「二つのタスクで2種類のセマフォ取得順序が逆だから」は妥当です。

誤りやすいポイント

  • メッセージ送信部分だけに原因があると考え、セマフォ取得順序の違いを見落とす。
  • 「割込み処理が停止させた」といったハードウェア側の原因を疑い、ソフトウェア資源の競合を後回しにしてしまう。
  • 同じバイナリセマフォを使っているから安全だと早合点し、取得順序統一の原則を思い出さない。

FAQ

Q: メッセージキューのサイズ不足でタスクが止まる可能性はありませんか？
A: 本設問ではメッセージキューの容量についての記述はなく、問題文が強調しているのは「二つのセマフォ取得順序の不一致」です。従って主因はデッドロックです。
Q: 割込み優先度を調整すればデッドロックは回避できますか？
A: 優先度を変えても循環待ち条件が残る限りデッドロックは発生します。取得順序を統一するか、タイムアウト付き取得などの設計変更が必要です。
Q: バイナリセマフォをミューテックスに変えれば解決できますか？
A: ミューテックスも排他制御の基本原理は同じで、取得順序を誤ればデッドロックになります。資源階層法などで順序を明確化することが根本対策です。
関連キーワード: デッドロック、セマフォ、排他制御、資源階層法

設問3：

本文中のb〜eに入れる適切な字句を解答群の中から選び、
解答群 　ア：オーディオデバイス 　イ：音声データ領域 　ウ：実行 　エ：実行可能 　オ：着信音設定情報 　カ：待ち 　キ：メッセージ 　ク：メモリ残量 　ケ：優先 　コ：利用者設定領域 　サ：録音時間 　シ：録音詳細情報

模範解答

b：エ c：ウ d：コ e：カ

解説

解答の論理構成

  1. 前提確認
    問題文には「UIタスクの優先度は高、録音タスクの優先度は低」とあります。優先度が高いタスクはレディ（実行可能）になるとただちに CPU を獲得し、低いタスクはプリエンプトされます。
  2. (イ) でメッセージを送信した直後の状態判定
    原文「録音タスクからUIタスクにメッセージを送信した場合　録音タスクはb状態となり、UIタスクはc状態となった。」
    • メッセージを受信した UI タスクはレディキューに入り、優先度が高いため直ちに CPU を得ます。したがって UI タスクは“実行”状態。
    • 低優先度の録音タスクは CPU を奪われるのでレディキューに残ります。これは OS 用語で“実行可能”状態。
      よって
      b＝エ「実行可能」
      c＝ウ「実行」
  3. UI タスクが取得できなかったセマフォ
    原文「UIタスクはdセマフォを取得できず、e状態となった。」
    図3の処理手順は「利用者設定領域セマフォを取得」→「音声データ領域セマフォを取得」の順です。録音タスクは図4で先に「音声データ領域セマフォ」を取得し、その後「利用者設定領域セマフォ」を取得するため、(イ) の時点では両セマフォを保有しています。したがって UI タスクが最初に取りに行く「利用者設定領域セマフォ」が取れません。
    d＝コ「利用者設定領域」
  4. 取れなかった結果の状態
    セマフォ取得に失敗したタスクはブロックされ OS の“待ち”状態になります。
    e＝カ「待ち」
  5. まとめ
    b：エ「実行可能」
    c：ウ「実行」
    d：コ「利用者設定領域」
    e：カ「待ち」

誤りやすいポイント

  • 「実行」と「実行可能」を混同しやすい
    CPU を実際に使っているのが「実行」、使えずにレディキューで待っているのが「実行可能」です。
  • UI タスクが取得に失敗するセマフォの取り違え
    図3では先に「利用者設定領域セマフォ」を取りに行くので、こちらがボトルネックになります。
  • “待ち”と“実行可能”の区別
    セマフォ待ち・イベント待ちは“待ち”。プリエンプトで CPU を失っただけなら“実行可能”です。

FAQ

Q: 「待ち」状態から復帰するタイミングはいつですか？
A: UI タスクが要求する「利用者設定領域セマフォ」を録音タスクが解放した瞬間にレディ（実行可能）へ遷移し、再び優先度判定で CPU を獲得します。
Q: 二つのタスクが動かなくなったケース(ア)はなぜ起こるのですか？
A: (ア)ではセマフォ取得順序が UI と録音で逆になり、双方が相手のセマフォ待ちでブロックされる“デッドロック”が発生するためです。
Q: 優先度反転の対策は必要ありませんか？
A: 今回は「高優先度(UI)がセマフォ待ちでブロック→低優先度(録音)が実行できない」ため優先度逆転は起きませんが、一般論としては優先度継承方式などで対処します。
関連キーワード: プリエンプション、バイナリセマフォ、デッドロック、タスク状態、優先度制御
戦国ITクイズ機能

\ せっかくなら /

応用情報技術者を
クイズ形式で学習しませんか？

クイズ画面へ遷移する→

すぐに利用可能！

©︎2026 情報処理技術者試験対策アプリ

このサイトについてブログプライバシーポリシー利用規約特商法表記開発者について