0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

マルチプロセスとマルチスレッドについて説明して!

「マルチプロセスとは,独立した仮想アドレス空間を持つプロセス群をOSカーネルのスケジューラがコンテキストスイッチによって時分割多重実行する並行実行モデルです.一方,マルチスレッドは,同一プロセス内で複数のスレッドコンテキストがコードセグメントやヒープを共有しつつ,各スレッドが独立したスタックやレジスタセットを保持し,CPUアフィニティやキャッシュコヒーレンシ,メモリバリア,CAS,NUMA,フォールスシェアリング,IPC,TLS,...」


うわあああぁぁあぁあぁあ~~~~~😱

となってしまうでしょう.Qiitaの記事を読んでいても,難しい言葉をさらに難しい言葉で説明しているように感じることがあります.

もちろん,そういった記事を悪いと言いたいわけではありません.正確に説明する,技術者同士で簡潔に会話するにあたって専門用語は欠かせないものです.

しかし,理解する段階でこんな調子では全く身が入りません.私は新しい技術を学ぶとき,まず「要は何?」を考えるようにしています.現実のものに例えたり,比較したり,既に知っている知識へ当てはめたりして,自分の言葉で理解する.

この記事では,そんな私の考え方を紹介します.

お品書き

1.仕組みを抽象化して考える
2.比較して考える
3.「何が良いの?」の視点で見る
4.現実に例えて考える
5. 全体像を知ってから詳しく学ぶ
6.まとめ

各章に「マルチプロセスとマルチスレッドで例えると」を記述しています.

仕組みを抽象化して考える

技術を一言でいうとどんなものなのか,本質だけを抜き出して考えます.

細かい仕組みはいったん置いておき,「これは何なのか」をつかむことで,全体像を理解しやすくなります.

マルチプロセスとマルチスレッドで例えると

マルチプロセス
 → 仕事を分担する仕組み

マルチスレッド
 → 仕事を分担する仕組み

これと次章以降を合わせることで,技術の本質とその周りの関係が見えてきますね.

比較して考える

新しい技術を学ぶときは,すでに知っている技術との共通点や違いを考えます.

「ここは同じだけど,ここが違う」という視点で見ることで,それぞれの技術の役割や特徴が見えやすくなります.

マルチプロセスとマルチスレッドで例えると

共通点
 → どちらも並行に仕事を進めるための仕組み
 
違い
 → 1プロセス = 複数スレッド
 → メモリ空間を共有するかどうか

「何が良いの?」の視点で見る

私は,新しい技術を見るときは「これがあると何が嬉しいの?」と考えるようにしています.

多くの技術は,何かしらの問題を解決するために生まれています.
そしてそれが 特徴(またはメリット) となっていることが多いため,仕組みを細かく覚える前に「何を解決したい技術なのか」を知るだけでも,理解しやすさは大きく変わります.

マルチプロセスとマルチスレッドで例えると

マルチプロセス

なぜある?
 → 安全に並行処理をしたい

その代わり
 → プロセス生成は重い
マルチスレッド

なぜある?
 → プロセスを作るほどのコストをかけずに並行処理したい

その代わり
 → 共有資源の管理が難しい

現実に例えて考える

ここまで見てきた内容を,今度は自分の知っている世界へ持っていきます.
そうすることで,技術同士の関係や設計思想もイメージしやすくなります.
私は「これって現実世界で例えると何だろう?」と考えながら理解することが多いです.

マルチプロセスとマルチスレッドで例えると

プロセス → 飲食店
スレッド → そこで働くバイト

マルチプロセス → 飲食店を複数経営する
マルチスレッド → 1店舗でバイトをたくさん雇う

マルチスレッドのメリット
 → 新しく店を建てるよりコストが低い
 → 店の設備(厨房・レジ・食材など)を共有できる

マルチスレッドのデメリット
 → 一人の従業員が問題を起こしたら,店ごと終わる
 → レジや厨房など共有設備で取り合いが起きる

 マルチプロセスのメリット
 → 店舗が独立しているので,一店舗が火事になっても他の店は営業できる
 → 店舗ごとに責任を分けやすい

 マルチプロセスのデメリット
 → 店舗を建てるコストが高い
 → 店舗間で食材をやり取りするのが面倒
  • 「新しく店舗を建てるよりコストが低いから,スレッドを使うメリットがあるんだな」
  • 「レジが取り合いになるから,同時に使えないようにする仕組みが必要だな」→ ロック
  • 「レジが2台,3台になる.セルフレジになる.それに伴って設計が難しくなるな」
  • 「だったら,レジ1つ&1人しか使えないってした方が楽じゃない?」→ 共有を減らす設計LWKT

というように,1つの例えで周辺のOSの設計思想まで自然につながります.

全体像を知ってから詳しく学ぶ

もちろん,上記の考え方だけで技術を深く理解できるわけではありません.

しかし,「要は何?」という全体像を先に知っているだけで,その後に公式ドキュメントや技術記事を読んだときの理解度は大きく変わると感じています.

内容を知らない英語の記事を読むときも,

「これは昨日の大統領選挙についての記事です」

と一言だけ事前に教えてもらった方が,内容を追いやすくなります.
同じように,技術も最初に全体像をつかんでおくことで,細かい仕組みが頭の中でつながりやすくなります.

現在はAIという「翻訳役」がいます.難しい技術を簡潔に説明してもらい,全体像をつかんでから公式ドキュメントへ進む,という学び方もしやすくなりました.

そのため私は,最初から100%理解しようとはせず,「要は何?」 というマップを頭の中に作ってから,詳しい資料を読むようにしています.

まとめ

技術を学んでいると,専門用語が次々と出てきます.でも,大切なのは専門用語を覚えることではなく,「要は何?」を自分の言葉で説明できるようになることです.現実に例えたり,比較したり,既存の知識に当てはめたりしながら考えることで,難しい概念も少しずつ理解しやすくなります.

専門用語に支配されるのではなく,専門用語を自分の知識で翻訳する.
私は,そんな学び方を大切にしています.

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?