今日使用されている並行プログラミングのパラダイムと方法は数多くあります。ソフトウェア トランザクション メモリ、アクター、共有状態の同時実行、タプル スペース、その他多数。
ただし、私が不足していると思うのは、並行性に関する興味深いテスト問題のライブラリです。よく知られている例の 1 つは、「食の哲学者問題」です。次に、作業の分散のみを必要とする多くの並列アルゴリズム (行列乗算、レンダリング、一般的なネストされたデータ並列処理) がありますが、実行スレッド間の通信との実際の同時実行は必要ありません。
では、並行性パラダイムの例として使用するのに十分単純な、インタラクティブな、おそらく分散環境でさえも実際の並行性を必要とするいくつかの興味深い問題のセットを誰か教えてもらえますか? 理想的には、同時実行パラダイムの「ラックマス テスト」として機能する一連の問題を見つけたい (または、すべてのパラダイムには長所と短所があるため、それらの違いを強調する)。
どんな助けでも大歓迎です:)
I've previously considered this exact issue, having previously proposed some concurrent programing paradigms myself :p
The conclusion I reached then is that such a test set doesn't seem to really exist in a language-independent manner. While it might be helpful for it to exist, there seem to be some fairly good reasons it doesn't (to the best of my knowledge).
Most of the focus within concurrent programming tends to be on data parallelism, such that the same operation is applied in parallel to different pieces of the same data set. The kinds of task-level parallelism (i.e. different tasks being performed in parallel, possibly sharing data) that I think you're talking about is actually not done very much. I think this is because it's kinda hard. But I think it's also kinda hard because most problems don't lend themselves particularly well to this kind of concurrency. Describing a distributed system in terms of concurrency primitives may be helpful, but these systems tend to be decoupled such that there is a protocol (written or implied) moderating their communication. People tend not to think of these kinds of systems as obviously "concurrent" programming situations, even though they are when viewed within the right frame (i.e. considering the "client" and "server" as agents operating in parallel with synchronisation at some points).
The only places I think you could find some sources of inspiration would be within individual implementations. Erlang, Occam (and Occam-pi), Alice, CML, Concurrent Haskell etc all are likely to have small test corpuses, but both the problems and their implementations are going to be biased towards being implementable within a specific language (because they obviously are implementable within that language!). Perhaps you could also look to the communities working on multi-party session types, and various process calculi such as pi-calculus, CCS and CSP to see what kinds of systems they are using as example models. The idea of a standard language-agnostic set of problems for describing concurrent communicating systems is appealing, but somewhat elusive at this point, I think.