関数型プログラミングの学習

第6章. 並行性の問題

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

私はこの章を、少し神秘的に聞こえる文章で始めようと思う：状態の変異がなければ、時間を無視することができる。

これを紐解いてみよう。まず第一に、時間と状態の変異、あるいはプログラミングと何の関係があるのだろうか？プログラミングに時間が入るのは、特定の順序で実行される必要のある一連のプロセスがあるときだ。

次の例を考えてみよう。¹つの関数を考える。最初の関数はxをx+ 1にする。もう1つはxを x×xに変換する。さて、この2つの関数を並列実行することを想像してみよう。答えはどうなるだろうか？正解が5つもあることに驚くだろうか？これを分解してみよう。P1=x→x×xとし、P2=x→x+ 1 とする：

• P1が xを100にセットし、次にP2が100を101にセットすれば、101が得られる。

• P2が xを11にセットし、P1が11を121にセットすれば、121が得られる。

• この場合、110が得られる。

• P2は xにアクセスし、P1は xを100にセットする。次にP2は xをセットする。

• P1は xに2回アクセスする。次にP2は xを11にセットする。次にP1は xをセットする。

正解はどれだろう？101、121、110、10、それとも100？それはプログラマの意図による。ポイントは、P1とP2を並列実行させただけでは、どの答えが返されるかはわからないということだ。なぜなら、コンピュータはこれら2つの関数の評価を、それ以前のどの順序で行うかを決めることができるからだ。

注

ステートが変異した場合、プロセスの実行順序が重要になる。

これはどうすればいいのだろうか？理想的なのは、、共有された可変性の状態を持たないことだ。共有され、可変性のある状態とは何か？共有とは、少なくとも2つの異なるスレッドがアクセスしているということであり、可変性とは、それが変化するということである。ここで問題が発生する可能性がある。共有可変型状態がなければ、関数の呼び出し順は問題にならない。共有された可変性の状態を避けることが不可能な場合、カプセル化することが次善の策となる。ここでの考え方は、共有された変更可能な状態をできるだけ小さな領域に留めておくことだ。

カプセル化された、可変性のある共有ステートに特に適したプログラミング・モデルのひとつに、アクター・モデルがある。次にそれを検証する。

ウィキペディアの俳優モデルのページより：

コンピュータサイエンスにおけるアクターモデルは、アクターを並行計算の普遍的なプリミティブとして扱う、並行計算の数学的モデルである。アクターは、メッセージを受信したレスポンスとして、ローカルな決定を行い、さらにアクターを作成し、さらにメッセージを送信し、次に受信するメッセージへの応答方法を決定することができる。アクターは自分自身のプライベート・ステートを変更することができるが、メッセージングを通じて間接的にしか互いに影響を与えられない（ロック・ベースの同期の必要性がなくなる）。

ロック・ベースの同期とは、、一度に1つのスレッドだけがコードの一部にアクセスできるようにすることだ。これは、共有された可変性の状態の問題に対する伝統的なアプローチのひとつである。

注

アクター・モデルは、並行システムや分散システムを記述するための高度な抽象化を提供する。開発者が明示的なロックやスレッド管理に対処する必要がなくなるため、正しい並行システムや並列システムを記述しやすくなる。 ...