並列処理システムの設計の勘所は「スレッドを使わない事」だ

　当ブログのスレッド数決定問題にて、並列処理システム設計をする上でスレッドを決定する事の難しさと大切さを説きました。その中で既に言及していますが、重要なので強調した記事を書きます。
　システム設計に於いて、リソースの使用は大事な検討課題です。具体的には、リソース対象を特定し、そのリソースが何byteのデータか、そして権限はどうするのかまで考えなくてはなりません。そうしないと、ネットワーク設計・データベース設計・セキュリティ設計は出来ません。データ量が分からずとして、システムの拡張性と安定性は確保できませんし、使用するリソースと権限が分からずとしてセキュリティ対策は出来ません。となれば、同様の理由でデータベース設計も出来ません。
　並列システムの設計では熟考するべきリソースは、現状のOSを考えると「スレッド数」と「CPUのコア数」です。OSの設計思想が変わり、スレッドモデル以外が選択されれば、もちろんその何かになります。それに関連して、データベース設計の視点から見ると、リクエスト数の内容が関係してきます。つまり、ハードウェアリソースと、それに対応付けられているソフトウェアリソースは重要なのです。
　スレッド数の決定とくれば、多くの人は使用する事ばかりを考えてしまいます。しかしながら、リソースを使用する事ばかりを考えると、ハードウェアがそれに追いつきません。コア数が32個あっても足らず、64個、128個、256個...と「もっとコアを！」状態になるのは目に見えています。何故ならば、既に現状でスレッドを使い過ぎているからです。
　タスクマネージャを見てみましょう。貴方のPCでどれだけのスレッド数が要求されているでしょうか？確認すれば32個以上のスレッドを使っているのが分かると思います。それを踏まえずとして、「このシステムで使うアプリケーションは、コア数を最大限に使用しよう」などととんでもない設計をすれば、アプリケーション数 * コア数となり、ハードウェアリソースが永遠に不足する酷いシステムが出来上がります。
　とはいえ、「スレッドを使わないために絶対に並列処理をしない」などというのは馬鹿げた極論です。この様なシステム方針にしてしまうと、ハードウェアを増強したら処理が速くなると考えているエンドユーザーの期待を裏切ってしまいます。これはあってはならない事です。
　相反する事を書いているように見えるかもしれませんが、当たり前の一つの真実を言っています。それは、リソースを考えて使用する事の大切さです。あればあるだけリソースを使いきるのは愚かな行為ですし、だからと言ってリソースを使わないのもまた愚かな行為です。リソースは、必要な時に必要なだけ使用しなくてはなりません。すなわち、リソースを使用する判断と、リソースを使わない判断もせねばならないのです。
　最近は潤沢なハードウェアリソースと、便利な開発ツールを活かした富豪プログラミングと富豪設計が行われている節がありますが、どのような資源も無限ではありません。私達技術者はリソースのコントロールが求められています。今はまだ表面化していないかもしれませんが、電機事情が複雑になってきた時代背景を鑑みると、これからの時代はリソースのコントロールが当たり前の要求となるのは目に見えています。
　私達は昔では考えられなかった、潤沢なハードウェアリソースとソフトウェアリソースを手にしています。しかし、それら豊富なリソースは有限であり、リソースを意識せずにシステム設計および実装をすると、何時か化けの皮がはがれます。従って、技術者は常にリソースのコントロールが求められていると考えるのが妥当です。プロフェッショナルらしく、リソースを巧みに使用する技術者を一緒に目指しましょう。
　そうすれば私達情報技術者は、尊敬のまなざしを受ける職業になるでしょう。

スレッド数決定問題16

　この記事はスレッド数決定問題15の続きです。前回は、並列処理システム設計技法の概要を解説しました。今回は、順序的な依存性と並列性について解説します。
　あらゆる処理には前提と順序が存在します。並列処理システムの設計に不慣れな人は、順序があるから並列化出来ないと考えてしまいます。しかし、どんな処理でも順序があるのにも関わらず、現実には並列化されている処理は色々あります。もし順序があれば並列処理が出来ないのであれば、あらゆる処理は並列化出来ない事になります。従って、見方を変えれば並列化できると結論付けられます。
　具体的には、情報の抽象度を変える事により処理を並列化できます。例えば、厳密な順序が決まっている処理Aがあるとします。この処理Aだけを見れば並列化できないかもしれません。しかしながら、処理Aを包含する処理Bに視点を移せば話しは変わってきます。処理B内で処理Aを複数同時実行できるかもしれません。
　この例から分かると思いますが、並列処理化の対象はできるだけ抽象度が高い処理にします。インテル社のCPUが良い例です。プロセッサ内の処理をユニットに分け、パイプライン処理などの高度な並列処理をしています。つまり、抽象度が高いオブジェクトを定義しておけば、内部の処理を並列化する事が可能となるという事です。
　総括します。システムを並列化するには、従来の直列的なアルゴリズムの発想で設計してはなりません。並列特有の問題点を知り、今までとは違う視点でシステムを設計せねばなりません。もちろんこれは分析段階にも言えます。システムのどの部分を並列化するのかを決めるには、並列処理で必要となる情報を収集せねばなりません。これらの事柄を面倒に感じる人がいるでしょう。
　しかしながら、現在に於いて並列処理は必要不可欠な技術であり、その効果も高いので避けては通れません。並列処理はパフォーマンスを向上させますが、システムの構成も変化するので、新しい発想のシステムが実現できます。苦労は多いですが、その分見返りも大きいのです。並列処理を学習し、お客様が喜ぶシステムを構築しましょう。

スレッド数決定問題15

　この記事は、スレッド数決定問題14の続きです。今回は、いよいよ並列処理システムの設計法について解説します。
　これまでの記事の内容を前提とした上で、高度な並列処理技術を使用するシステムの設計について述べていきます。並列処理システムを設計するには、先ず並列処理はどのような分類があるのかを知らねばなりません。並列処理を大別すると、データの並列化とタスクの並列化の2つです。
　データの並列化は、対象のデータを並列的に処理する事を指します。企業における情報処理システムは、データが増える事はあっても減る事はありません。その大量のデータを並列的に処理するのは自然な考え方です。
　タスクの並列化は、データではなく処理そのものを並列化する方法です。タスクの並列化は、仕事の現場において多々見受けられる光景です。殆どの仕事は、複数の人が同じ内容の仕事をしています。それがタスクの並列化と考えると分かりやすいかと思います。タスクの並列化もまた、自然な考え方だと言えます。
　現実をモデル化する上で、データの並列化とタスクの並列化は容易に見出す事が出来ます。コンピュータの世界とは違い、現実はあらゆる出来事が並列的に起こっています。それ故、初めて並列処理システムを設計する人は、簡単な事だと思うでしょう。しかし、現実とコンピュータの世界のギャップがシステム設計を困難にします。その困難さについては、今で述べてきたので、改めてこの連載を読むと分かるかと思います。
　現実とコンピュータのギャップを埋める並列処理システムの設計に於いて重要なのは、依存性を明らかにする事です。普段我々人間は、日常では依存性を気にしませんが、コンピュータ上では意識しなくてはなりません。全ての処理には何らかの前提と順序的な依存性があります。それを明確にしないと、並列処理システムの設計は行えません。続く...

GUIは何故シングルスレッドなのか

　恐らく、GUIプログラミングをした事がある人は、多くのGUIフレームワークがシングルスレッドである事を知っているでしょう。ですが、GUIフレームワークがシングルスレッドである理由を知らない人は多いと思います。今回は並行処理をする上で、必ずぶちあたる疑問である「GUIフレームワークがシングルスレッドである理由」を解説します。
　その理由を理解するには、GUIの性質および仕組みとロックについて知らねばなりません。先ずはロックについておさらいしましょう。
　並行処理時において、共有メモリ上にある1つのリソースに複数の処理が同時アクセスする場合、整合性がある結果を得るためにロックをしなければなりません。ロックをしなければ、リソースの状態は不整合になり、正しい処理結果を得られません。ですが、ロックの使用は細心の注意が必要になります。不適切なロックをすれば、デッドロックなどの深刻な問題が発生します。これを念頭に置き、GUIフレームワークについて考えましょう。
　GUIフレームワークは、ユーザーにウインドウやコントロールを表示し、マウスやキーボードなどのポインティングデバイスでアプリケーションを操作する事を可能とします。あまりに身近なので、その事について深く考えた事がない人が多いでしょう。しかしながら、この一見当たり前の要求がシングルスレッドにしなくてはならない理由と深く結びついています。
　私達は知らないうちに、GUIに関して多くの前提を持っています。そのうちの一つが、「操作した順に結果が得られる」事です。ですが、並行処理でこの当たり前の事を実現するのは困難です。私達が普段使用するOSは、リアルタイムOSではありません。ですからOSは時間を厳守出来ません。従って、操作した順にプログラムが処理される事を前提に出来ません。
　多くのGUIフレームワークは、メッセージループを使用し実装しています。例えばマウスがクリックされた時、マウスがクリックされた事を知らせるメッセージが、メッセージキューに追加されます。そうしたメッセージをループで処理する事によりGUIフレームワークは描画処理など行っています。この実装方式が問題になります。
　操作した順に結果を得るには、メッセージキューへ順序良くメッセージを追加せねばなりません。もしそうしなければ、処理結果が画面に表示された後でボタンがクリックされる不自然な描画になるかもしれません。そうした不自然な挙動は誰も望んでいません。この様な人間にとって当たり間のGUIに関する前提を並行処理で実現するのは大変困難です。
　何故ならば、1つしかないリソースであるメッセージキューを並行的に扱う事になるからです。メッセージキューへ複数のスレッドがアクセスする場合、先に述べたように慎重にロックをしなくてはなりません。そうしなければ、デッドロックなどの問題が発生します。これは開発者に対し、慎重なプログラミングを要求する事を意味します。しかしながら、多くのプログラマはGUIで複雑なロック規約を守る事を望みません。ですから多くのGUIフレームワークは、スレッドローカルストレージ等の技法を活用し、シングルスレッドにより簡潔なGUIプログラミングが出来るようにしています。
　ならば、マルチスレッドが前提のGUIフレームワークを実装すればよいと考える人もいるでしょう。ですが、既存の資産が問題になります。例えば、Windowsのクリップボードサービスはシングルスレッドが前提です。それら過去の資産を活かすには、シングルスレッドにするしかありません。また、並行処理を熟知した開発者が数多くいなければなりません。
　纏めます。GUIがシングルスレッドである理由は、メッセージの順番を保持したままロックするのが困難だからです。それに加え、過去の資産と人材が問題になります。時がたつにつれそれらの問題は解消されるでしょうが、当分の間GUIフレームワークはシングルスレッドであり続けるでしょう。

スレッド数決定問題14

　この記事は、スレッド数決定問題13の続きです。引き続き、最適なスレッド数を決定する方法について語ります。
　設計をする際には、従来のスレッドモデルの並行処理ではなく、インテルTBBの様な並列処理特有の考え方をする方が、設計の負担が少なくなります。インテルTBBの様な並列処理を扱う時は、この処理は並列化するというふうに抽象化して考えます。ただし、全てを並列化するなどというふうに、無目的な抽象化をしてはなりません。今まで述べてきたように、CPUという貴重なリソースを有効に使用するべきです。システムを設計する際には、局所的に常に並列化するのではなく、全体的にCPUの利用率が最適になる様に考えなくてはなりません。
　それを実現するには、実装を知らなくてはなりません。昨今はフレームワークなどがあるから詳細を知る必要がないと誤解している人々がいますが、それではプロとして通用しません。その技術がどのように実現されているのかを知って、初めてプロフェッショナルと言えるでしょう。
　それを考えると、昔よりも今の方が要求される情報量が増加しています。それに加えて、抽象化により思わぬ不利益を被ることもあります。例えば、個々のアプリケーションが無目的にCPUの全てのコアを使用する場合、2つのアプリケーションを立ち上げるだけで、PCに過負荷がかかってしまうかもしれません。
　どんな技術でもそうなのですが、過剰な使用は毒となります。特に並列化の場合、バグの発生率が高くなり、CPUへの負担が一気に高くなります。それを防ぐために、並列化の技術は高度に抽象化され、物理的なスレッドに直接対応していません。しかしながら、そうした論理スレッドを使用すると、今度は設計が難しくなります。
　今までと同じ考え方では、高度に抽象化されている並列処理の技術は使いこなせません。従来のスレッドモデルを使用した並行処理とは違う考え方が必要となります。続く...

並列処理プログラミングとテストの基礎

　並列処理プログラミングを実務で使用するには、一つの難題をクリアしなくてはなりません。それは、並列処理アルゴリズムの正当性をどのように確認するのかです。並列処理プログラミングは、処理が行われるタイミングが影響するので、直列的アルゴリズムよりもテストが難しくなります。そこで、並列処理システムを構築した時の経験をもとに、テストテクニックの基礎を秘密保持契約に違反しない範囲で書きます。
　テストの基本はユニットテストです。ユニットテストが正しく実施されていなければ、テストを実施しないと同じだという事が出来ます。ユニットテストをプログラミングしないという選択肢は考えられません。テストファーストを実施すれば、生産性が下がる主張する人もいます。ですが、実際は正しくユニットテストを行えば、生産性は上がります。
　テストファーストを採用すれば生産性が上がる理由は、実務でしている作業を思い起こせば分かります。実務では、プログラミングをしている時間よりも、処理を頭の中で描く時間と、動作チェックの時間の方が長いはずです。新人の頃は、無闇にプログラミングをします。しかし、熟練するに従って無駄なプログラミングを初めからしなくなります。熟練者は頭の中でシミュレーション出来るので、無駄なプログラミングをする必要がなくなります。これは、どの業務でも同じで、熟練すればするほど無駄な動作が減るという事を意味します。従って、初めからユニットテストを書くと、思考作業とチェック作業が一体化し、生産性が上がるという主張の正しさが分かって頂けると思います。
　並列処理プログラミングでのユニットテストは、直列処理（逐次処理）プログラミングで行います。何故ならば、並列処理プログラミングでテストコードを書くと、テストコードの正当性をチェックする必要が生じてしまうからです。テストコードをテストするコードを書くのは無駄な行為なので、成功率が高い直列処理を行うテストコードをコーディングします。
　通常のユニットテストが成功すれば、次にタイミングを変えるテストコードを埋め込みます（プリプロセッサ併用が望ましい）並列処理は、任意のタイミングで処理が実行されます。従って、故意にタイミングを変えてチェックする必要があるのです。具体的には、Sleep関数などを使用し、どの時点で違うスレッドに処理が移っても正しい結果になるかチェックします。どの部分に埋め込むかについては、並行処理プログラミングを習得すれば分かります。分からない場合は、並行処理プログラミングを学びましょう。
　後は並行処理に対応した開発ツールを使用しましょう。開発ツールを使用すれば、効率よく並行処理プログラミングが出来ます。並行処理対応の開発ツールに対する出費を出し惜しみすれば、人件費が余計にかかります。並列処理をするのであれば、並列処理対応の開発ツールは必須です。
　以上の事を実施すれば、基本的なテストはOKだと思います。応用技術に関しては、開発対象に依存するものが多く、秘密保持契約に違反せずに紹介するのが難しいので、今回は紹介できません。ですが、おそらく不可能ではないので、別の機会に紹介できるかもしれません。

スレッド数決定問題13

　この記事は、スレッド数決定問題12の続きです。引き続き、最適なスレッド数を決定する方法について語ります。
　今まで述べてきたように、最適なスレッド数を決定するのは困難です。この連載を読んだ人の中には、絶望してしまった人がいるかもしれません。ですが、希望があります。スレッドを管理する機能を、設計＆実装するのは、ご想像通り非常に困難であり、私もその事に関する思い出が沢山あります。しかしながら、昨今はその複雑さを軽減する技術があります。
　スレッドプール、インテルTBB、OpenMP、PPL...といった、スレッドを自動管理してくれる技術が存在します。しかし、銀の弾丸は存在しません。設計を正しく行わないと、どれほど便利な技術でもバグの元です。高度で便利な技術があるからといって、何も考えなくてもよいという事ではありません。その技術を深く知る必要あります。
　例えば、スレッドプールを使用しても、並列処理を入れ子状態にして、連続呼び出しをするとパフォーマンスが悪化し、恐らくエラーも発生するでしょう。また、入れ子が可能なインテルTBBを使用しても、無闇に使うとパフォーマンスの低下とエラーが発生するのは同じです。この様に、どれだけ高度な技術を使おうとも、考えずにシステム開発は出来ません。並行処理の知識を持ち、使用する技術を深く知らねばなりません。
　これらの技術を使用すると、並列処理が抽象化され、オブジェクト指向設計がやりやすくなります。ただし、技術について知らないと、正しい設計を行う事が出来ません。設計時に実装の詳細を決定してはならないのですが、実装を知らなくてもよいという事を意味しておりません。続く...

スレッド数決定問題12

　この記事は、スレッド数決定問題11の続きです。引き続き、最適なスレッド数を決定する方法について語ります。
　前回述べたように、スレッド数の決定は、全行程に影響を与え、設計段階と実装段階をまたがっている問題です。これは、本質的な問題で、どちらか一方で解決できる問題ではありません。その理由は、アムダールの法則と関係しております。
　アムダールの法則を簡潔に表現すると、どれだけ多くのCPUを搭載しても、プログラムに直列部分がある限り、パフォーマンスは期待通りに向上しないという事を示しています。例えば、コア数が2のCPUを搭載しても、処理スピードは2倍になりません。何故ならば、全てのプログラムが並行で動作するのではなく、直列的に動く部分があるので、直列部分が足を引っ張って2倍の処理速度を得られないからです。アムダールの法則を考慮すれば、プログラムは極力並列化するべきだと言えます。
　ここで、オブジェクト指向設計と、オブジェクト指向プログラミングで、如何にしてスレッド数を決定するのかという難題が立ちふさがります。オブジェクト指向設計の段階では、実装の詳細に踏み込んではなりません。しかしながら、実装段階に任し過ぎると、有限の資源であるCPUが上手く活用できず、並列処理特有の問題が発生する確率が高まります。並列処理時に起こる問題を避けて、スレッドを使用しないのは問題ですし、何も考えずにスレッドを生成しすぎるのもまた問題です。システム全体の視点と、個々のロジックという詳細な視点の両方が必要となります。

スレッド数決定問題11

　この記事はスレッド数決定問題10の続きです。引き続き、コーディング規約などの実装段階における、スレッド関連の問題を語ります。
　並列処理を実装するにあたって忘れてはならないのは、想定する処理時間はどれくらいなのかを明記する事です。明記しておかないと、不注意なプログラマが長時間を要する並列処理を、連続して呼び出してしまうかもしれません。そんな馬鹿な事をしないと、思われる方がいるかもしれません。ですが、コードは再利用されるので、実装の詳細を知らないプログラマが、コードを扱う可能性がありますし、並列処理を知らないプログラマも沢山います。さらに最悪な状況ですと、テストデータが不十分で潜在的なエラーが発現せず、本稼働した後に障害が発生する可能性すらあります。また、深刻な障害が起きずに、パフォーマンス劣化などの形で表れるかもしれません。こうした不都合は積み重なります。ある意味、システムが早期にストップするよりも性質が悪いエラーだと言えるかもしれません。それらの不都合を避けるために、およその処理時間をAPIドキュメントなどに明記しましょう。そうすれば、並列処理特有のエラーをある程度避けられます。
　今回はもうひとつ重要な事を挙げます。それは、オブジェクトの事前条件・事後条件・不変表明です。並列処理プログラミングを行っていても、非オブジェクト指向言語を使っていない限り、オブジェクト指向プログラミングの事も考慮せねばなりません。並列処理を行った場合、並列処理特有の条件がありうるので、十分な注意が必要です。表明を正しく行う事により、並列処理特有のエラーも減らせます。
　数回に渡って、実装段階の注意点を述べてきました。これらの事柄はスレッド数の決定に関連しています。何故ならば、オブジェクト指向設計を行った段階で、スレッド数を厳密に決定する事は不可能だからです。オブジェクト指向設計では、実装段階の事から切り離して考えます。しかし、並列処理は実装に依存する部分が多く、予め全てを予想する事は不可能に近い事です。単純なソフトウェアならば、プログラマが勝手にスレッドを使用しても問題ないかもしれませんが、システム規模になると、それでは問題が生じます。実装段階で判明した事を考慮しつつ、設計を微調整せねばなりません。
　続く・・・

スレッド数決定問題10

　この記事はスレッド数決定問題9の続きです。引き続き、コーディング規約などの実装段階における、スレッド関連の問題を語ります。
　並行処理を行う場合、例外処理のポリシーを注意深く決めなくてはなりません。何故ならば、並列処理を行うと、例外処理の扱いが一層難しくなるからです。具体的に言うと、他のスレッドで例外が発生した場合どうするのかを決めなくてはなりません。決めておかないと、潜在的なエラーが多いシステムが出来上がるでしょう。
　こうした事もあり、例外処理のポリシーは、直列的な処理をしている場合でも難しいのですが、並列処理ではより一層難しくなります。その対処法については、今のところ言語依存です。何故ならば、言語およびライブラリごとに扱い方が異なるからです。各言語の並列処理に関する機能および、例外処理に関する機能と、並行処理をサポートするライブラリをよく調べましょう。特にGUIは注意が必要です。GUIは並行処理が難しい分野であり、並行処理をする際には十分に注意せねばなりません。
　例外処理ポリシーが決まったら、今後のために内容が分かるようにせねばなりません。オブジェクト指向プログラミングでは、コードの再利用率が高くなりますし、コードは長い間保守されます。開発時のメンバーがいない状況でも、並列処理を行うコードを容易に把握できる状態にしておきましょう。
　続く・・・