マルチスレッドが難しい理由を説明する方法

私はかなり良いプログラマーであり、上司もかなり良いプログラマーです。彼はマルチスレッドなどのいくつかのタスクを過小評価しているように見えますが、それがどれほど難しいかはわかりません（いくつかのスレッドを実行し、すべてが完了するのを待ってから結果を返す以上のことは非常に難しいと思います）。

デッドロックや競合状態を心配し始めた瞬間、私はそれを非常に難しいと感じますが、上司はこれを感謝していないようです-私は彼がこれに遭遇したことはないと思います。ロックをたたくだけで、態度はほぼ変わりません。

それでは、どうやって彼を紹介したり、なぜ彼が並行性、並列処理、マルチスレッドの複雑さを過小評価しているのかを説明できますか？または多分私は間違っていますか？

編集：彼がやったことのほんの少し-リストをループし、そのリストの各アイテムに対して、そのアイテムの情報に基づいてデータベース更新コマンドを実行するスレッドを作成します。一度に実行されるスレッドの数を彼がどのように制御したかはわかりません。実行中のスレッドが多すぎる場合（キューはセマフォを使用しなかった場合）、キューに追加する必要があります。

1. 数学的経験を頼りにできる場合は、本質的に決定論的な通常の実行フローが、複数のスレッドで非決定論的になるだけでなく、指数関数的に複雑になることを説明してください。紛失した更新またはダーティリードの状況の簡単な例は、しばしば目を見張るものです。

2. 「ロックを平手打ち」は簡単な解決策です。パフォーマンスを気にしない場合は、すべての問題を解決します。たとえば、アトランタの誰かが1冊の本を注文するたびにAmazonが東海岸全体をロックしなければならなかった場合、どれだけのパフォーマンスヒットが発生するかを説明してください。

マルチスレッドは簡単です。マルチスレッド用のアプリケーションのコーディングは非常に簡単です。

簡単なトリックがあります。これは、適切に設計されたメッセージキューを使用して（独自にロールしないで）スレッド間でデータを渡すことです。

難しいのは、複数のスレッドが何らかの方法で共有オブジェクトを魔法のように更新しようとすることです。人々は現在の競合状態に注意を払わないため、エラーが発生しやすくなります。

多くの人はメッセージキューを使用せず、共有オブジェクトを更新し、自分で問題を作成しようとします。

困難になるのは、複数のキュー間でデータを渡すときに適切に機能するアルゴリズムを設計することです。それは難しいです。しかし、（共有キューを介して）共存するスレッドの仕組みは簡単です。

また、スレッドは I / Oリソースを共有することに注意してください。I / Oにバインドされたプログラム（つまり、ネットワーク接続、ファイル操作、またはデータベース操作）は、多くのスレッドで高速化することはほとんどありません。

共有オブジェクトの更新の問題を説明する場合、それは簡単です。たくさんの紙のカードを持ってテーブルに座ってください。4〜6個の単純な計算式の簡単な計算セットを書き留めてください。

これがゲームです。あなたはそれぞれ式を読み、答えを書き、その答えが書かれたカードを置きます。

各自が半分の作業を行いますよね？半分の時間で完了しましたよね？

上司があまり考えずに開始したばかりの場合は、何らかの形で矛盾が生じ、両方が同じ式に答えを書きます。書く前に読んでいる二人の間に固有の競合状態があるため、それはうまくいきませんでした。同じ式を読んだり、お互いの答えを上書きしたりすることを妨げるものは何もありません。

ひどくロックされていない、またはロックされていないリソースで競合状態を作成する方法はたくさんあります。

すべての競合を回避する場合は、用紙を数式のスタックに分割します。キューから1つを取り出し、回答を書き留めて、回答を投稿します。どちらも読み取り専用のメッセージキューから読み取るため、競合はありません。

マルチスレッドプログラミングは、おそらく同時実行性の最も難しいソリューションです。基本的には、マシンが実際に行うことの非常に低レベルの抽象化です。

アクターモデルや（ソフトウェア）トランザクションメモリなど、はるかに簡単なアプローチがいくつかあります。または、不変のデータ構造（リストやツリーなど）を操作します。

一般的に、懸念事項を適切に分離することにより、マルチスレッド化が容易になります。人々が20個のスレッドを生成し、すべてが同じバッファを処理しようとすると、忘れられがちです。同期が必要な場所でリアクタを使用し、通常はメッセージキューを使用して異なるワーカー間でデータを渡します。
アプリケーションロジックにロックがある場合、何か間違ったことをしました。

そのため、技術的には、マルチスレッドは困難です。
「ロックを平手打ち」は、同時実行性の問題に対するほとんどスケーラブルでないソリューションであり、実際にはマルチスレッドの目的全体を無効にします。それは、問題を非並行実行モデルに戻すことです。実行すればするほど、その時点で実行されているスレッドは1つだけになります（デッドロックの場合は0）。それは全体の目的を無効にします。
これは、「第三世界の問題を解決するのは簡単です。ただ爆弾を投げてください」と言っているようなものです。些細な解決策があるからといって、結果の質を気にするので、これは問題を些細なものにしない。

しかし、実際には、これらの問題を解決することは、他のプログラミングの問題と同様に困難であり、適切な抽象化を行うのが最善です。実際、これは非常に簡単です。

この質問には非技術的な角度があると思います-IMOは信頼の問題です。たとえば、Facebookなどの複雑なアプリを再現するように頼まれます。私は、タスクの複雑さを未経験/管理者に説明しなければならない場合、デンマークで何かが腐っているという結論に達しました。

他の忍者プログラマが5分でタスクを実行できたとしても、あなたの推定はあなたの個人的な能力に基づいています。あなたの対談者は、その問題についてあなたの意見を信頼することを学ぶか、彼らが受け入れる言葉を持っている人を雇うべきです。

課題は、人々が会話を通じて無視する傾向があるか、把握できない技術的意味を伝えることではなく、相互尊重の関係を確立することです。

デッドロックを理解するための簡単な思考実験の1つは、「食事の哲学者」問題です。競合状態がどれほど悪いかを説明するために私が使用する傾向がある例の1つは、Therac 25の状況です。

「ロックをたたくだけ」とは、マルチスレッドで難しいバグに遭遇したことのない人の考え方です。そして、彼はあなたが状況の深刻さを誇張していると考えている可能性があります（私はそうではありません-特に車で終わる組み込みソフトウェアでは、競合状態のバグで物を爆破したり、人々を殺すことは可能です）。

同時アプリケーションは決定論的ではありません。プログラマが脆弱であると認識している非常に少量のコード全体では、スレッド/プロセスの一部が別のスレッドの一部に関連して実行されるタイミングを制御できません。テストはより難しく、時間がかかり、すべての並行性関連の欠陥を見つける可能性は低いです。欠陥が見つかった場合、微妙であることが多く、一貫して再現できないため、修正が困難です。

したがって、唯一の正しい同時アプリケーションは、おそらく正しいと思われるアプリケーションであり、ソフトウェア開発ではあまり実践されていません。結果として、メッセージの受け渡しは比較的簡単に正しいことを証明できるため、S.Lotによる回答が最良の一般的なアドバイスです。

2つの言葉での短い答え：観測可能な非決定性

長い答え：問題を考慮して、使用する並行プログラミングへのアプローチに依存します。書籍Concepts、Techniques、and Models of Computer Programmingで、著者は並行プログラムを書くための4つの主な実用的アプローチを明確に説明しています：

• 順次プログラミング：並行性のないベースラインアプローチ。
• 宣言的並行性：観測可能な非決定性がない場合に使用できます。
• メッセージパッシングの同時実行性：多数のエンティティ間でのメッセージの同時受け渡し。各エンティティは内部的にメッセージを順次処理します。
• 共有状態の同時実行：スレッドは、粗雑なアトミックアクション（ロック、モニター、トランザクションなど）によって共有パッシブオブジェクトを更新します。

今、明らかにシーケンシャルプログラミングから離れてこれらの4つのアプローチの最も簡単である宣言型同時実行は、このアプローチを使用して書かれたプログラムを持っていないので、観察可能な非決定性を。言い換えると、競合状態は観察可能な非決定的動作であるため、競合状態はありません。

しかし、観測可能な非決定性の欠如は、宣言的並行性を使用して取り組むことができないいくつかの問題があることを意味します。ここでは、それほど簡単ではない最後の2つのアプローチが登場します。それほど簡単ではない部分は、観測可能な非決定性の結果です。現在、これらは両方ともステートフルコンカレントモデルに該当し、表現力も同等です。しかし、CPUあたりのコア数は増え続けているため、業界では最近、メッセージパッシングライブラリ（AVM for JVM）やプログラミング言語（Erlangなど）の増加に見られるように、メッセージパッシングの同時実行性に関心が集まっているようです。。

理論的なアクターモデルに支えられた前述のAkkaライブラリは、ロック、モニター、またはトランザクションを処理する必要がないため、同時アプリケーションの構築を簡素化します。一方、ソリューションを設計するための異なるアプローチ、つまり、アクターを階層的に合成する方法で考える必要があります。まったく異なる考え方が必要だと言うことができますが、これもまた、最終的には、単純な状態の共有同時実行を使用するよりもさらに困難になる可能性があります。

観察可能な非決定性のために並行プログラミングは困難ですが、特定の問題に対して適切なアプローチとそのアプローチをサポートする適切なライブラリを使用すると、多くの問題を回避できます。

私は最初に、2つのスレッドを開始し、それらを両方とも1から100まで同時にコンソールに出力する単純なプログラムを見ることで問題を引き起こす可能性があると教えられました。の代わりに：

1
1
2
2
3
3
...

次のようなものが得られます。

1
2
1
3
2
3
...

もう一度実行すると、まったく異なる結果が得られる場合があります。

私たちのほとんどは、コードが順番に実行されると想定するように訓練されています。ほとんどのマルチスレッドでは、これを「箱から出して」当然のことと見なすことはできません。

いくつかのハンマーを使用して、ハンマーを保持している人とのやり取りをせずに、狭い間隔の釘を一度につぶしてみてください...（目隠しされていると仮定します）。

これをエスカレートして家を建てます。

あなたが建築家であると想像して、夜眠りましょう。:)

簡単な部分：セマフォ、キュー、インターロックカウンター、アトミックボックス型など、フレームワーク、オペレーティングシステム、ハードウェアの最新機能を備えたマルチスレッドを使用します。

難しい部分：そもそも機能を使用せずに機能を実装します。ハードウェアの非常に限られた機能を除き、複数のコアにわたるクロッキングの一貫性の保証のみに依存する場合があります。