応用情報技術者 2023年 秋期 午後 問08
スレッド処理に関する次の記述を読んで、設問に答えよ。
B社は、首都圏に約50店の美容室を運営する美容室チェーンである。B社では顧客に顧客カードを発行し、B社の全店舗で顧客カードを持参した顧客に割引価格でサービスを提供している。近年、テレワークなどで外出機会が減ったことによって、顧客の来店回数が減少しており、売上げが減少傾向にある。
そこでB社では、顧客に美容室に来てもらうために販売促進活動を行うことにした。この販売促進活動の一つとして、スマートフォン向けサービス(以下、新サービスという)を提供することにした。この新サービスの開発は、B社のWebサイトの構築経験がある情報システム担当のCさんが担当することになった。
〔新サービスの機能〕
Cさんは新サービスの開発に向けて、全店舗の店長から“顧客にもっと来店してもらうためのアイディア”を募った。集まったアイディアを基にCさんが考えた新サービスのトップ画面と四つの機能を図1に示す。

〔新サービスを提供するアプリケーションソフトウェア〕
次にCさんは、新サービスを提供するためのアプリケーションソフトウェア(以下、アプリケーションという)について調査した。その結果、アプリケーションの代表的な種類には、
aとbがあることが分かった。aは、サーバでHTMLを生成してスマートフォンに送信する。スマートフォンのOSの差異を考慮した開発は不要だが、カメラやGPSなどのデバイスの利用が一部制限される。一方□b□は、それ自体をスマートフォンにインストールして実行するもの(以下、スマホアプリという)である。OSの差異を考慮した開発が必要であるが、カメラやGPSなどのデバイスを制限なく利用できる。この調査結果からCさんは、新サービスはbとして開発することを提案し、上司の承認を得た。
〔トップ画面の開発〕
次にCさんは、Java言語を用いてスマホアプリのトップ画面の開発に着手した。トップ画面を実装し、画面の描画処理の中で、顧客番号に関連付けられた顧客氏名、来店日付、担当美容師氏名の情報をサーバから取得して画面に表示する処理を行うようにした。しかし、このスマホアプリを実行したところ並行処理に関するエラー(例外)が発生し、スマホアプリの実行が中断された。
このエラーの原因を究明するために、スマートフォン上で動作するGUIアプリケーションにおける並行処理を行う仕組みに関して調査を行った。スマートフォンのOS上で処理を実行するための仕組みとしてcとdとがある。cは、独立したメモリ空間を割り当てて実行されるものであり、多くの場合アプリケーションの実行単位ごとに一つのcで実行される。一方dは、一つのメモリ空間を共有しながら実行されるもので、一つのcの中で、複数のdを実行することができる。
GUIアプリケーションの開発では、画面描画、画面操作などの画面ユーザーインタフェースに関する処理を行うメインスレッドと、メインスレッドと並行して比較的処理時間が長い処理を行う①バックグラウンドスレッド(以下、ワーカースレッドという)とを分けて実装する必要がある。また、ワーカースレッドによる画面ユーザーインタフェースに関する処理は禁止されていることが分かった。
そこで、トップ画面の処理をメインスレッドとワーカースレッドとに分けて実装することにし、トップ画面を完成させた。
〔おすすめの髪型機能の開発〕
次にCさんは、おすすめの髪型機能の開発に着手した。おすすめの髪型機能の実現に必要な処理を表1に示す。なお、表1中の開始条件とは当該処理の実行を開始するために必要な条件であり、処理時間は当該処理の実行に必要なスマートフォン内の計算時間と標準的な通信時間の合計時間である。

表1の七つの処理を行うために、②メインスレッドと二つのワーカースレッドを作成して処理を行うプログラムを実装した。処理4と処理5は並行に実行できるので、別々のワーカースレッドで処理することにした。このとき、処理6の実行の開始条件は処理4と処理5が共に完了していることなので、二つのスレッドの完了を待ち合わせるe操作を処理6のプログラムに記載した。
Cさんは、処理1~処理7で構成されるおすすめの髪型機能を実装してテスト用に準備したスマートフォンで実行したところ、通信環境の良い場所では正常に動作したが、通信環境が悪い場所ではサーバからの応答を待ち続けてしまう問題が発生した。この問題を解決するために③処理5のプログラムにある処理を追加した。
その後、Cさんはスマホアプリの全ての機能の開発とテストを完了させ、B社は新サービスを用いた販売促進活動を開始した。
設問1:
本文中のa、bに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:Javaアプレット
イ:Webアプリケーション
ウ:コンソールアプリケーション
エ:ネイティブアプリケーション
模範解答
a:イ
b:エ
解説
解答の論理構成
- 問題文は次のように説明しています。
・「aは、サーバでHTMLを生成してスマートフォンに送信する。スマートフォンのOSの差異を考慮した開発は不要だが、カメラやGPSなどのデバイスの利用が一部制限される。」
・「一方bは、それ自体をスマートフォンにインストールして実行するもの(以下、スマホアプリという)である。OSの差異を考慮した開発が必要であるが、カメラやGPSなどのデバイスを制限なく利用できる。」 - この特徴はクラサバ型 Web システムと、端末に直接インストールするアプリの典型的な比較です。
・サーバ側で HTML を生成し端末のブラウザで表示する=「Webアプリケーション」。
・端末 OS 上で直接動作し各種デバイス API を自由に呼び出せる=「ネイティブアプリケーション」。 - 解答群を照合すると
ア:Javaアプレット(ブラウザプラグイン型で時代遅れ)
イ:Webアプリケーション(要件と合致)
ウ:コンソールアプリケーション(文字主体で不適切)
エ:ネイティブアプリケーション(要件と合致)
したがって
・a=「イ:Webアプリケーション」
・b=「エ:ネイティブアプリケーション」
誤りやすいポイント
- 「HTML を生成して送信する」という記述だけで「Javaアプレット」を連想し選択肢アを選んでしまう。アプレットはバイトコードを送る仕組みであり HTML のみではない点に注意。
- 「インストールして実行する」という表現から PC 上のソフトも含むと思い込み「コンソールアプリケーション」を選ぶケース。モバイル文脈では OS API を直接呼ぶネイティブアプリケーションを指す。
- デバイス制約の有無と OS 依存性の対応関係を逆に覚えていると選択肢が逆転する。
FAQ
Q: Webアプリケーションでもカメラや GPS を使えるのでは?
A: 最近は HTML5 の getUserMedia などで利用できる場面もありますが、ネイティブ API と比べ機能・性能・端末依存の制約が残るため「一部制限される」という表現が用いられています。
A: 最近は HTML5 の getUserMedia などで利用できる場面もありますが、ネイティブ API と比べ機能・性能・端末依存の制約が残るため「一部制限される」という表現が用いられています。
Q: ネイティブアプリケーションとハイブリッドアプリの違いは?
A: ネイティブは画面描画からロジックまで OS のネイティブ言語・フレームワークで実装します。ハイブリッドは WebView 上に HTML/CSS/JavaScript を配置し、必要に応じてネイティブプラグインでデバイス API を呼び出す方式です。本問では純粋ネイティブを前提としています。
A: ネイティブは画面描画からロジックまで OS のネイティブ言語・フレームワークで実装します。ハイブリッドは WebView 上に HTML/CSS/JavaScript を配置し、必要に応じてネイティブプラグインでデバイス API を呼び出す方式です。本問では純粋ネイティブを前提としています。
Q: Javaアプレットは現在も利用できますか?
A: 主流ブラウザがプラグイン機構を廃止したため実質的に利用できません。試験では歴史的用語として出題されることがありますが、モバイル向けではありません。
A: 主流ブラウザがプラグイン機構を廃止したため実質的に利用できません。試験では歴史的用語として出題されることがありますが、モバイル向けではありません。
関連キーワード: Webアプリケーション、ネイティブアプリケーション、モバイル開発、デバイスアクセス、OS依存
設問2:〔トップ画面の開発〕について答えよ。
(1)本文中のc、dに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:イベント
イ:ウィンドウ
ウ:スレッド
エ:プロセス
模範解答
c:エ
d:ウ
解説
解答の論理構成
- 問題文では、スマートフォン OS 上での実行単位を
“cは、独立したメモリ空間を割り当てて実行されるものであり、多くの場合アプリケーションの実行単位ごとに一つのcで実行される。”
と記述しています。
― 独立したメモリ空間を持つものはプロセスであるため、選択肢「エ:プロセス」が一致します。 - 続いて、
“一方dは、一つのメモリ空間を共有しながら実行されるもので、一つのcの中で、複数のdを実行することができる。”
とあります。
― 共有メモリ空間内で複数実行される単位はスレッドであるため、選択肢「ウ:スレッド」が該当します。 - 以上より
c=「エ:プロセス」
d=「ウ:スレッド」
が解となります。
誤りやすいポイント
- “独立したメモリ空間”と“共有しながら実行”を逆に読んでしまい、c と d を入れ替えるミス。
- GUI の用語に引きずられて「ウィンドウ」を選んでしまうケース。
- “イベント”を並行処理の単位と誤解し、dに選んでしまうケース。
FAQ
Q: プロセスとスレッドの主な違いは何ですか?
A: プロセスは OS から独立したメモリ空間を割り当てられ、他プロセスとメモリを共有しません。スレッドは同一プロセス内でスタック以外のメモリを共有し、文脈切替が軽量です。
A: プロセスは OS から独立したメモリ空間を割り当てられ、他プロセスとメモリを共有しません。スレッドは同一プロセス内でスタック以外のメモリを共有し、文脈切替が軽量です。
Q: スレッドを増やすと必ず並列実行できますか?
A: 論理 CPU 数を超えると完全な並列実行はできず、OS がタイムシェアリングで切り替えます。また同一メモリ空間共有に伴う排他制御が必要です。
A: 論理 CPU 数を超えると完全な並列実行はできず、OS がタイムシェアリングで切り替えます。また同一メモリ空間共有に伴う排他制御が必要です。
Q: スマートフォン開発でメインスレッドとワーカースレッドを分ける理由は?
A: 画面描画・入力処理を担当するメインスレッドがブロックされると UI が固まり、ユーザ体験が損なわれるためです。重い処理や通信はワーカースレッドに委譲します。
A: 画面描画・入力処理を担当するメインスレッドがブロックされると UI が固まり、ユーザ体験が損なわれるためです。重い処理や通信はワーカースレッドに委譲します。
関連キーワード: プロセス、スレッド、メモリ空間、並行処理、GUI
設問2:〔トップ画面の開発〕について答えよ。
(2)本文中の下線①について、ワーカースレッドで実行すべきではない処理を解答群の中から選び、記号で答えよ。
解答群
ア:サーバから取得した情報を画面に表示する処理
イ:サーバからのレスポンスを待つ処理
ウ:サーバヘリクエストを送信する処理
エ:ホスト名からIPアドレスを取得しTCPコネクションを確立する処理
模範解答
ア
解説
解答の論理構成
-
問題文では、スマートフォン上の GUI アプリケーションにおいて
“画面描画、画面操作などの画面ユーザーインタフェースに関する処理を行うメインスレッド” と
“比較的処理時間が長い処理を行うバックグラウンドスレッド(以下、ワーカースレッド)” を分ける必要があると述べています。
さらに “ワーカースレッドによる画面ユーザーインタフェースに関する処理は禁止されている” と明記されています。 -
したがって、ワーカースレッドで実行してはいけないのは「画面ユーザーインタフェースに関する処理」、すなわち画面に何かを表示・更新する処理です。
-
解答群を確認すると
ア:「サーバから取得した情報を画面に表示する処理」
は UI の更新そのものです。これは禁止事項に該当するので ワーカースレッドで実行すべきではありません。 -
他の選択肢
イ:「サーバからのレスポンスを待つ処理」
ウ:「サーバへリクエストを送信する処理」
エ:「ホスト名から IP アドレスを取得し TCP コネクションを確立する処理」
はいずれもネットワーク I/O や待機処理であり、むしろメインスレッドをブロックしないためにワーカースレッドで実行すべき処理です。
以上より、ワーカースレッドで実行すべきではない処理は【ア】となります。
誤りやすいポイント
- 「レスポンス待ち」や「通信開始」は重い処理だからメインスレッドで行うべき、と思い込んでしまう。
- “画面表示” を CPU が軽い処理と誤解し、ワーカーでも問題ないと考えてしまう。
- “UI 更新はメインスレッド専用” というスマホアプリ開発の基本原則を忘れがち。
- 並列化の目的を「速度向上」とだけ捉え、UI 応答性維持という観点を抜かしてしまう。
FAQ
Q: 画面に表示する前にデータ変換だけを行う場合はワーカースレッドで良いですか?
A: はい。データ変換や画像加工など UI に触れない処理はワーカースレッドで問題ありません。表示(UI 更新)だけをメインスレッドに渡します。
A: はい。データ変換や画像加工など UI に触れない処理はワーカースレッドで問題ありません。表示(UI 更新)だけをメインスレッドに渡します。
Q: UI 更新を誤ってワーカースレッドで行った場合、必ず例外が発生しますか?
A: 多くの環境では実行時エラー(例外)になるか警告が出ますが、サイレントに動く場合もあります。再現性が低くバグが潜伏しやすいので原則として禁止されています。
A: 多くの環境では実行時エラー(例外)になるか警告が出ますが、サイレントに動く場合もあります。再現性が低くバグが潜伏しやすいので原則として禁止されています。
Q: ワーカースレッドで通信処理を行う理由は何ですか?
A: 通信は遅延が大きく、メインスレッドで実行すると UI がフリーズします。バックグラウンドで処理し、完了時に UI スレッドへ結果を渡すことで操作性を保てます。
A: 通信は遅延が大きく、メインスレッドで実行すると UI がフリーズします。バックグラウンドで処理し、完了時に UI スレッドへ結果を渡すことで操作性を保てます。
関連キーワード: UIスレッド、バックグラウンド処理、同期・非同期、ネットワークI/O, 例外ハンドリング
設問3:〔おすすめの髪型機能の開発〕について答えよ。
(1)本文中の下線②について、表1中の処理2〜処理7のうちメインスレッドで実行すべき処理だけを、表1中の処理名で全て答えよ。
模範解答
処理2, 処理7
解説
解答の論理構成
- 【問題文】では、メインスレッドが担当する役割について
「画面描画、画面操作などの画面ユーザーインタフェースに関する処理を行うメインスレッド」と明記し、さらに「ワーカースレッドによる画面ユーザーインタフェースに関する処理は禁止」と述べています。 - 表1の各処理の内容を確認すると、ユーザーインタフェースに直接関わるのは次の二つだけです。
・「処理2 画面に“処理中”のメッセージを表示する。」
・「処理7 処理6で合成した写真を画面に表示する。」
いずれも“画面に表示”という UI 操作を伴うため、メインスレッドで実行しなければなりません。 - 他の処理(“顔の特徴点を抽出”“画像を合成”など)は計算や通信が主体であり、UI 操作を含まないためワーカースレッドに振り分けるのが適切です。
- 以上より、メインスレッドで実行すべき処理は【表1】中の「処理2, 処理7」となります。
誤りやすいポイント
- 「処理6」は合成結果を生成するだけで「画面表示」を伴わない点を見落としがちです。
- “短時間ならメインスレッドで良い”と誤解して処理3や処理4をメインスレッドに載せると、UI フリーズの原因になります。
- 「処理1」はカメラ映像を表示しますが、問題の対象は「処理2〜処理7」であることを忘れて選択肢に入れてしまうミス。
FAQ
Q: 処理2や処理7をワーカースレッドで呼び出し、メインスレッドに結果を返す形でも良いですか?
A: 可能ですが、最終的な UI 更新は「メインスレッドで実行」する必要があります。コールバックやハンドラを経由してメインスレッドに処理を委譲する実装になります。
A: 可能ですが、最終的な UI 更新は「メインスレッドで実行」する必要があります。コールバックやハンドラを経由してメインスレッドに処理を委譲する実装になります。
Q: メインスレッドで実行すべき処理をワーカースレッドに誤って配置するとどんな不具合が起こりますか?
A: スマートフォン OS では例外(例えば “Only the original thread that created a view hierarchy can touch its views.”)が発生し、アプリが強制終了します。
A: スマートフォン OS では例外(例えば “Only the original thread that created a view hierarchy can touch its views.”)が発生し、アプリが強制終了します。
Q: 「通信待ち」もメインスレッドで行うと問題になりますか?
A: はい。通信は時間が読めないためワーカースレッドに任せ、結果が得られた時点でメインスレッドに UI 更新を依頼する方式が推奨されます。
A: はい。通信は時間が読めないためワーカースレッドに任せ、結果が得られた時点でメインスレッドに UI 更新を依頼する方式が推奨されます。
関連キーワード: メインスレッド、ワーカースレッド、UI 更新、非同期処理、例外処理
設問3:〔おすすめの髪型機能の開発〕について答えよ。
(2)本文中のeに入れる適切な操作名を解答群の中から選び、記号で答えよ。
解答群
ア:break
イ:fork
ウ:join
エ:wait
模範解答
e:ウ
解説
解答の論理構成
-
【問題文】には
“処理4と処理5は並行に実行できるので、別々のワーカースレッドで処理することにした。このとき、処理6の実行の開始条件は処理4と処理5が共に完了していることなので、二つのスレッドの完了を待ち合わせるe操作を処理6のプログラムに記載した。”
とあり、ポイントは「二つのスレッドの完了を待ち合わせる」ことです。 -
Java などの一般的なスレッド API で「スレッドの終了を待つ」操作は join() です。
例:
java thread4.join(); thread5.join(); -
解答群との対応を確認すると
・ア:break … ループ脱出
・イ:fork … プロセス生成(UNIX 系)
・ウ:join … スレッド待機
・エ:wait … オブジェクト監視待機(モニタ機構)
したがって要件に合致するのは “ウ:join” です。
誤りやすいポイント
- 「wait も“待つ”だから正しいのでは?」と勘違いしやすい
wait は同期化ブロック内でモニタを開放して待機する低レベル機構で、スレッドの終了待機には使いません。 - fork とスレッドを混同する
fork は【問題文】で説明された “c”=プロセスを複製する操作であり、スレッド制御とは別の文脈です。 - join を呼び忘れる/片方だけ呼ぶ
2本とも待たないと「処理6」の前提が崩れ、合成画像作成に失敗します。
FAQ
Q: join は重い操作ですか?
A: いいえ、単に対象スレッドが終了するまで現在のスレッドをブロックするだけで、CPU を占有しません。
A: いいえ、単に対象スレッドが終了するまで現在のスレッドをブロックするだけで、CPU を占有しません。
Q: wait と notify/notifyAll はいつ使うのですか?
A: スレッド間で共有リソースの状態変化を待つ場合に使います。終了待ちのように単純な場面では join の方が安全かつ簡潔です。
A: スレッド間で共有リソースの状態変化を待つ場合に使います。終了待ちのように単純な場面では join の方が安全かつ簡潔です。
Q: join 待ちを回避して非同期化する方法は?
A: コールバックや Future で完了通知を受け取る、あるいは CountDownLatch 等の高水準同期クラスを利用する方法があります。
A: コールバックや Future で完了通知を受け取る、あるいは CountDownLatch 等の高水準同期クラスを利用する方法があります。
関連キーワード: スレッド、join, 同期、非同期処理、排他制御
設問3:〔おすすめの髪型機能の開発〕について答えよ。
(3)本文中の下線③について、Cさんが追加した処理の内容を20字以内で答えよ。
模範解答
一定時間でタイムアウトする処理
解説
解答の論理構成
-
事象の把握
【問題文】では「通信環境が悪い場所ではサーバからの応答を待ち続けてしまう問題が発生した」とあります。
すなわち、ネットワーク応答が返らない場合に処理5が永久待ち状態(デッドロックではなくハング)となり、後続処理6・7へ進めなくなることが原因です。 -
制約条件の整理
処理5は「処理3で抽出した特徴点をサーバに送信し、おすすめの髪型の画像を取得する」ネットワーク I/O です。
ネットワーク通信は外部要因(電波状態・サーバ負荷)によって無限に遅延し得るため、アプリが稼働を継続するには待機時間を制限する必要があります。 -
解決策の導出
一般的に I/O 待ちが長引く場合の対処は
・一定時間で待機を打ち切りエラー処理へ遷移
・再試行やユーザへの通知
などですが、本設問は「待ち続けてしまう」状況を根本的に防ぐことが目的です。
よって「一定時間を超えたらサーバ応答待ちを中断する」タイムアウト機構を追加するのが最小限にして本質的な対応となります。 -
解答
③で追加した処理は「一定時間でタイムアウトする処理」です。
誤りやすいポイント
- 再試行(リトライ)を解答に書いてしまう
タイムアウト後に再試行する実装は考えられますが、設問は「追加した処理」のみを問うており、まずは待機を打ち切る機構が必須です。 - 進捗ダイアログや「キャンセル」ボタンの追加と誤解する
進捗表示は UI 改善であり、根本的に無限待ちを防げません。 - 排他制御(ロック解除)と混同する
本問題は通信待ち時間の問題であり、スレッド間の排他制御ではありません。
FAQ
Q: タイムアウト時間は何秒ぐらいに設定するべきですか?
A: 一般的にはモバイル通信の品質とユーザ体験のバランスを取り、3〜10 秒程度が多いです。アプリの要件やサーバ応答時間に応じて調整します。
A: 一般的にはモバイル通信の品質とユーザ体験のバランスを取り、3〜10 秒程度が多いです。アプリの要件やサーバ応答時間に応じて調整します。
Q: タイムアウト後はどのようにユーザへ通知すればよいでしょうか?
A: ダイアログで「通信に失敗しました。再試行しますか?」などと表示し、再試行ボタンやキャンセルボタンを用意するとユーザビリティが向上します。
A: ダイアログで「通信に失敗しました。再試行しますか?」などと表示し、再試行ボタンやキャンセルボタンを用意するとユーザビリティが向上します。
Q: タイムアウト実装はワーカースレッド側とメインスレッド側のどちらで行いますか?
A: 通信処理自体はワーカースレッドで行い、タイムアウト発生時にメインスレッドへエラー状態を通知して UI 更新(メッセージ表示など)を行う設計が推奨されます。
A: 通信処理自体はワーカースレッドで行い、タイムアウト発生時にメインスレッドへエラー状態を通知して UI 更新(メッセージ表示など)を行う設計が推奨されます。
関連キーワード: タイムアウト、非同期通信、ワーカースレッド、ネットワーク遅延、ハングアップ
設問3:〔おすすめの髪型機能の開発〕について答えよ。
(4)おすすめの髪型機能を実行するために必要な処理時間は何ミリ秒か。ここで、通信は標準的な時間で実行でき、表1に記載の処理時間以外については無視できるものとする。
模範解答
460(ミリ秒)
解説
解答の論理構成
-
依存関係の整理
表1によれば、各処理の開始条件は次のとおりです。
・「処理1」の開始条件は“なし”、処理時間は「100」。
・「処理2」の開始条件は“処理1の完了”、処理時間は「10」。
・「処理3」の開始条件は“処理1の完了”、処理時間は「100」。
・「処理4」の開始条件は“処理3の完了”、処理時間は「150」。
・「処理5」の開始条件は“処理3の完了”、処理時間は「200」。
・「処理6」の開始条件は“処理4、処理5の完了”、処理時間は「50」。
・「処理7」の開始条件は“処理6の完了”、処理時間は「10」。 -
スレッド配置
問題文に「処理4と処理5は並行に実行できるので、別々のワーカースレッドで処理することにした。」とあるため、- メインスレッド:処理1 → 処理2 → 処理7
- ワーカースレッドA:処理3 → 処理4
- ワーカースレッドB:処理5
という並行実行が可能です。
-
ガントチャートで時間軸を作成
0〜100ms メインスレッドで「処理1」(100)
100〜110ms メインスレッドで「処理2」(10)
100〜200ms ワーカースレッドAで「処理3」(100)
200〜350ms ワーカースレッドAで「処理4」(150)
200〜400ms ワーカースレッドBで「処理5」(200)
400〜450ms いずれかのスレッドで「処理6」(50)
450〜460ms メインスレッドで「処理7」(10) -
最長経路(クリティカルパス)の算出
0→100→200→400→450→460 と進む経路が最長で、その合計は
100 + 100 + 200 + 50 + 10 = 460(ミリ秒) -
以上より、必要な処理時間は「460(ミリ秒)」となります。
誤りやすいポイント
- 「処理2」と「処理3」は同時に開始できることを見落とし、直列に加算してしまう。
- 「処理4」と「処理5」を同じスレッドに置いてしまい、350→550msと誤って計算する。
- 「処理6」は両方の完了待ち合わせ後に開始できる点を忘れ、400msより前に足してしまう。
- クリティカルパスではなく単純合計(720ms)を答えてしまう。
FAQ
Q: なぜ「処理2」をメインスレッドに置くのですか?
A: 問題文で「画面に“処理中”のメッセージを表示する。」とあり、GUI 更新はメインスレッドで行うルールだからです。
A: 問題文で「画面に“処理中”のメッセージを表示する。」とあり、GUI 更新はメインスレッドで行うルールだからです。
Q: 「処理6」はどのスレッドで実行しても良いのですか?
A: 画面表示を伴わない合成処理なのでワーカースレッドでも構いません。クリティカルパスだけ把握できていれば、総処理時間は変わりません。
A: 画面表示を伴わない合成処理なのでワーカースレッドでも構いません。クリティカルパスだけ把握できていれば、総処理時間は変わりません。
Q: 通信環境が悪くても計算は変わりませんか?
A: 問題文に「通信は標準的な時間で実行でき」と明記されているため、表1の「200」をそのまま採用します。
A: 問題文に「通信は標準的な時間で実行でき」と明記されているため、表1の「200」をそのまま採用します。
関連キーワード: 並行処理、スレッド、クリティカルパス、同期、ガントチャート


