3

私は今、最終年度のプロジェクトを開始しています。Java と scala の観点から並行処理のアプローチを調査します。Java 並行性モジュールから抜け出した私には、共有状態のスレッド化アプローチが推論するのが難しいと人々が言う理由がわかりました。Java スレッドが非決定論的に動作するため、懸念すべき重要なセクションがあり、競合状態やデッドロックなどのリスクがあります。1.5 では、この推論はいくらか明確になりましたが、それでも明確にはほど遠いものでした。

一見すると、scala はアクター クラスを通じてこの複雑な推論を取り除いているように見えます。これにより、プログラマーは、よりシーケンシャルな視点から並行システムを開発し、概念化することが容易になりました。しかし、このポジティブな点について、いくつかの欠点があると私が言っているのは正しいでしょうか? たとえば、両方のシナリオで大きなリストを並べ替えたいとします。Java を使用して 2 つのスレッドを作成し、リストを 2 つに分割し、クリティカル セクション、アトミック アクションなどを心配してコードを実行します。scala では、「何も共有しない」ため、実際には list/2 を 2 つのアクターに渡してソート操作を実行する必要がありますよね?

私の質問は、より単純な推論に対して支払う代償は、スカラでコレクションをアクターに渡さなければならないというパフォーマンスのオーバーヘッドであると思いますか?

この効果のためにいくつかのベンチマーク テスト (選択ソート、クイック ソートなど) を行うことを考えていましたが、1 つは機能的でもう 1 つは必須であるため、アルゴリズムの観点からリンゴとリンゴを比較することはしません。

私を始めるためのいくつかのアイデアを私に与えるために、あなたが上記について持っている意見を本当に感謝します. どうもありがとう。

4

2 に答える 2

4

Scala の良いところは、必要に応じて Java の方法で並行処理を実行できることです。すべての Java クラスが利用可能です。

つまり、可変変数に同時にアクセスできるスレッドを持つモデルと、互いにメッセージを送信するが互いの内部をのぞき見しないステートフルなアクターを持つモデルとの違いに要約されます。そして、いくつかのシナリオでは、パフォーマンスとコードの修正の容易さをトレードオフする必要があるというあなたの意見はまったく正しいです。

大まかな経験則として、Javaモデルを使用して、ロックが開くのを待つのにかなりの時間を費やすスレッドの山があり、作業を分離する明確な方法がない場合全員がそのリソースを待機することを回避し、実行がスレッド間ですばやく切り替わる場合、Java モデルは、アクターが「完了しました」というメッセージをスーパーバイザーに送り返し、スーパーバイザーが送信するアクター モデルよりもはるかに優れています。 a「新作です！」既存の非ビジー アクターへのメッセージ。ソート アルゴリズムは、どのように想定するかに応じて、このカテゴリに分類されます。

他のほとんどの場合、アクターに関連するパフォーマンスの低下は、私が見た限りではそれほど大きくありません。問題を非常に多くのリアクティブな要素 (つまり、メッセージを受信したときにのみ必要とする) と考えることができる場合、アクターは特にうまくスケーリングできます (何百万もの利用可能ですが、特定の瞬間に機能するのはほんの一握りです)。 ; スレッドの場合、アクティブなスレッドをそれほど多く処理できないため、誰がどの作業を行うべきかを追跡するために、ある種の特別な内部状態が必要になります。

于 2011-03-16T22:28:42.273 に答える
3

ここで指摘しておきたいのは、Scala はアクターに渡された引数をコピーしないため、アクターは渡されたものを何でも共有できるということです。

Erlang とは対照的に、変更可能なものを共有しないようにするのはプログラマーの責任です。ただし、イミュータブルなものへのすべてのアクセスは読み取り専用であるため、ロックする必要がないため、不変のものを共有してもペナルティはありません。また、Scala は不変のデータ構造を強力にサポートしています。

于 2011-03-16T23:23:22.937 に答える