タグ付けされた質問 「concurrency」

データ競合とは何か、そしてロック/ミューテックス/セマフォがそれらを防ぐのにどのように役立つのかを理解しています。しかし、ロック自体に「競合状態」がある場合はどうなりますか？たとえば、おそらく同じアプリケーション内にあるが、異なるプロセッサで実行されている2つの異なるスレッドが、まったく同時にロックを取得しようとします。 それではどうなりますか？それを防ぐために何が行われますか？それは不可能ですか、それともまったくありそうもないことですか？それとも、実際に発生するのを待っている競合状態ですか？

24 multithreading  concurrency  locks 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 これは私が就職の面接で尋ねられた質問であり、彼らが探していた答えがわからないので、私はここの誰かがいくつかのアイデアを持っていることを望んでいます。目標は、同じ値を2回返さないことが保証されている関数を作成することです。この機能は、複数のマシンから同時にアクセスされると仮定します。 私のアイデアは、各マシンに一意のIDを割り当て、その値を一意の値ジェネレーター関数に渡すことでした。 var i = 0; function uniq(process_id, machine_id) { return (i += 1).toString() + machine_id + "-" + process_id; } これにより、2つ以上のプロセスがの同じ値を読み取った場合でもi、各戻り値にプロセスIDとマシンIDの一意の組み合わせがタグ付けされるため、競合状態からのフォールアウトが回避されます。ただし、別のマシンをオンラインにするにはIDを割り当てる必要があるため、私のインタビュアーはこの回答を好みませんでした。 だから誰もこれを解決する別の方法を考えることができますか？それは一意のIDを持つように各マシンを構成することを必要としませんか？この質問が再び出てくる場合に備えて、回答が欲しいです。ありがとう。

23 algorithms  concurrency 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 6年前に移行され ました。 私は質問があります、それはプログラマーが一般的に並行性とマルチスレッドプログラムを好むように思われる理由についてです。 ここで2つの主なアプローチを検討しています。 基本的に信号に基づく非同期アプローチ、または新しいC＃5.0などの多くの論文や言語で呼ばれる非同期アプローチ、およびパイプラインのポリシーを管理する「コンパニオンスレッド」 並行アプローチまたはマルチスレッドアプローチ 私はここでハードウェアと最悪のシナリオについて考えていると言いますが、この2つのパラダイムを自分でテストしました。物事をスピードアップしたり、リソースを有効に活用したい場合は、マルチスレッドについて話します。 CPU内にメモリコントローラーを提供しないIntelクアッドコアを備えた古いマシンでマルチスレッドプログラムと非同期プログラムをテストしました。メモリはマザーボードによって完全に管理されています。マルチスレッドアプリケーションでは、3-4-5のような比較的少数のスレッドでさえ問題になる可能性があり、アプリケーションは応答せず、遅くて不快です。 一方、優れた非同期アプローチはおそらく高速ではないかもしれませんが、最悪ではありません。私のアプリケーションは結果を待つだけでハングせず、応答性があり、はるかに優れたスケーリングが行われています。 また、スレッドの世界でのコンテキストの変更は、実際のシナリオではそれほど安くないことを発見しました。実際には、計算するために相互に循環してスワップする必要のあるスレッドが2つ以上ある場合、実際には非常に高価です。 現代のCPUでは、状況はそれほど違いはありませんが、統合されたメモリコントローラですが、私のポイントは、x86 CPUは基本的にシリアルマシンであり、メモリコントローラはマザーボード上の外部メモリコントローラを備えた古いマシンと同じように動作することです。コンテキストスイッチは依然としてアプリケーションに関連するコストであり、メモリコントローラーが統合されているか、新しいCPUに2コア以上あるという事実は私にとってはお買い得ではありません。 私が経験したコンカレントアプローチは理論的には良いが、実際にはそれほど良くありません。ハードウェアによってメモリモデルが課されているため、このパラダイムをうまく利用することは難しく、使用からデータ構造を複数のスレッドの結合に使用します。 また、両方のパラダイムは、特定の時点でタスクまたはジョブが実行されるときにセキュリティを提供しません。機能的な観点からは、それらは本当に似ています。 X86メモリモデルによると、なぜ大多数の人々は、非同期アプローチではなく、C ++で同時実行性を使用することを提案するのでしょうか。また、コンピュータの最悪のシナリオを考えてみてください。コンテキストスイッチは、おそらく計算自体よりも高価です。

23 multithreading  concurrency  x86 

私は2つのコンポーネントを持つ小さなシステムを開発しています。1つはインターネットリソースからデータをポーリングし、それをsqlデータに変換してローカルに保持します。2番目のものは、ローカルインスタンスからそのsqlデータを読み取り、jsonおよびrestful apiを介して提供します。 私はもともとpostgresqlでデータを永続化することを計画していましたが、アプリケーションには保存するデータとサービスするトラフィックの量が非常に少ないため、やり過ぎだと思いました。SQLiteは仕事をしているのですか？フットプリントが小さく、この1つのタスクのために別のSQLサーバーを維持する必要がないというアイデアが大好きですが、同時実行性が心配です。 先読みロギングを有効にすると、データベースからプロセスをロックアウトせずに、SQLiteデータベースの読み取りと書き込みを同時に行うことができるようです。 1つの読み取りと他の書き込みのみが行われる場合、単一のSQLiteインスタンスは、それにアクセスする2つの並行プロセスを維持できますか？私はコードを書き始めましたが、これがSQLiteの誤用かどうか疑問に思っていました。

22 web-development  python  sql  concurrency  sqlite 

FP支持者は、パラダイムが可変状態を回避するため、並行性は簡単であると主張しています。わかりません。 FPを使用して、純粋な機能と不変のデータ構造を強調するマルチプレイヤーダンジョンクロール（ローグライクゲーム）を作成していると想像してください。部屋、廊下、ヒーロー、モンスター、戦利品で構成されるダンジョンを生成します。私たちの世界は、事実上、構造とそれらの関係のオブジェクトグラフです。物事が変化すると、世界の表現はそれらの変化を反映するように修正されます。私たちのヒーローはネズミを殺したり、短剣を拾ったりします。 私にとって、世界（現在の現実）はこの状態の考え方を持ち、FPがこれをどのように克服するのか見逃しています。ヒーローが行動を起こすと、機能が世界の状態を修正します。すべての決定（AIまたは人間）は、現在の世界の状態に基づいて行う必要があるようです。並行性はどこで許可しますか？複数のプロセスが並行して世界の状態を修正することはできません。1つのプロセスの結果が期限切れの状態に基づいていることはありません。世界の現在のオブジェクトグラフで表される現在の状態を常に処理しているように、すべての制御は単一の制御ループ内で行われるべきだと感じています。 明らかに、並行性に完全に適した状況があります（つまり、状態が互いに独立している孤立したタスクを処理する場合）。 私の例では並行性がどのように役立つかを確認できず、それが問題になる可能性があります。私は何らかの形で主張を誤って伝えているかもしれません。 誰かがこの主張をよりよく表現できますか？

21 functional-programming  concurrency  state 

私は最近、職場で適用する必要があるかもしれないので、CQRS / ESに飛び込み始めました。多くの問題を解決するため、私たちのケースでは非常に有望です。 ES / CQRSアプリが、単純化された銀行のユースケース（出金）にコンテキスト化されたように見える方法についての大まかな理解をスケッチしました。 要約すると、Aがお金を引き出した場合： コマンドが発行されます 検証/検証のためにコマンドが引き渡される 検証が成功した場合、イベントはイベントストアにプッシュされます アグリゲーターはイベントをデキューして、集約に変更を適用します 私が理解したことから、イベントログは真実の源であり、FACTSのログであるため、それから予測を導き出すことができます。 さて、この壮大な計画の中で私が理解できないのは、この場合に何が起こるかです： ルール：残高をマイナスにすることはできません 人Aのバランスは100eです 人Aは100eのWithdrawCommandを発行します 検証に合格し、100eイベントのMoneyWithdrewEventが発行されます その間に、人Aは100eの別のWithdrawCommandを発行します 最初のMoneyWithdrewEventはまだ集約されていなかったため、検証は合格です。これは、集約に対する検証チェック（まだ更新されていないため） 100eのMoneyWithdrewEventがもう一度発行されます ==>残高が-100eで、ログに2つのMoneyWithdrewEventが含まれる一貫性のない状態です 私が理解しているように、この問題に対処するにはいくつかの戦略があります。 a）集約バージョンIDをイベントストアにイベントとともに配置し、変更時にバージョンの不一致がある場合、何も起こらない b）検証層が何らかの方法で作成する必要があることを意味する、いくつかのロック戦略を使用する 戦略に関する質問： a）この場合、イベントログはもはや真実の源ではありません。どう対処するのですか？また、引き出しを許可することは完全に間違っていましたが、クライアントに戻りましたが、この場合はロックを使用する方が良いですか？ b）ロック==デッドロック、ベストプラクティスに関する洞察はありますか？ 全体として、並行性の処理方法に関する私の理解は正しいですか？ 注：同じ人がこのような短い時間枠で2倍のお金を引き出すことは不可能であることを理解していますが、詳細に迷子にならないように簡単な例を取り上げました

20 concurrency  cqrs  event-sourcing 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 2年前に閉店。 コルーチンの基礎の大部分は60年代/​​ 70年代に発生し、その後、代替手段（スレッドなど）を支持して停止しました。 Pythonや他の言語で発生しているコルーチンへの新たな関心に対する実質はありますか？

19 python  multithreading  concurrency  multitasking 

私はErlangとGoプログラミング言語での並行プログラミングを検討していました。私の発見によると、それらはそれぞれアクターモデルとCSPを使用しています。 しかし、それでも私はCSPとアクターの客観的な違いは何かと混乱していますか？それは単に理論的に異なるだけで同じ概念ですか？

19 programming-languages  concurrency  concepts  go  erlang 

私は、並行プログラミングの非共有原則の下で働いてきました。基本的に、すべてのワーカースレッドには、同じ状態の不変の読み取り専用コピーがあり、それらは（参照によっても）共有されることはありません。一般的に言えば、これは非常にうまく機能しています。 現在、誰かがすべてのスレッドが同時にアクセスしているロックなしシングルトンキャッシュ（静的辞書など）を導入しています。辞書は起動後に変更されることはないため、ロックはありません。スレッドセーフの問題はありませんでしたが、現在はパフォーマンスが低下しています。 問題は...ロックがないため、このシングルトンの導入がパフォーマンスに影響を与えるのはなぜですか？これを説明できるカバーの下で正確に何が起こっていますか？ 確認するために、この新しいシングルトンにアクセスすることが唯一の変更であり、キャッシュへの呼び出しをコメントアウトするだけで確実に再作成できます。

19 c#  multithreading  concurrency 

私はなぜ食事哲学者の問題が5人の哲学者の事例に基づいているのかと思っていました。なぜ4つではないのですか？ 私たちは4人の思想家を与えられたときにも5人の哲学者の例を議論するときに発生する可能性があるすべての不快な問題を観察できると思います。それは歴史的な理由だけですか？

18 history  concurrency 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 DelayQueueの実際の使用法は何ですか？解決するために設計された一般的な問題は何ですか？

18 java  data-structures  concurrency 

2人の顧客が在庫が1品目のみの製品を同時に追加する場合を管理するためのベストプラクティスは何ですか？ これら2人の顧客の1人が同じ製品を追加するのを避けるために、バスケットのコードにチェックが必要ですか？ または、このチェックは、たとえば、関連する製品がまだ在庫にあることを確認するための2番目のクエリ（同時顧客がまだ購入していないことを意味する）を行う際に、支払いフェーズで実行する必要がありますか？

18 design  concurrency  locks 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 Erlangで使用されるアクターモデルは、並行プログラミングを行うための非常に異なる方法のようです。アクターモデルについてどう思いますか？並行性の一般的なソリューションになりますか？

18 concurrency  erlang  actor-model 

このフレーズまたは類似のフレーズは、時々発生します。一般的に、マルチコアプロセッサを最大限に活用するように設計されていないと主張するプログラムを指します。これは、特にビデオゲームプログラミングで一般的です。（もちろん、基本的なスクリプトなど、多くのプログラムには並行性がなく、それを必要としません）。 どうすればいいの？多くのプログラム（特にゲーム）は本質的に同時実行を使用し、OSはCPUのタスクスケジューリングを担当しているため、これらのプログラムは本質的に利用可能な複数のコアを利用していませんか？この文脈で「複数のコアを活用する」とはどういう意味ですか？これらの開発者は、実際にOSタスクのスケジューリングを禁止し、アフィニティまたは独自のスケジューリングを強制していますか？（大きな安定性の問題のように聞こえます）。 私はJavaプログラマーなので、抽象化やその他の理由でこれに対処する必要はなかったかもしれません。

17 multithreading  concurrency 

純粋に関数型またはほぼ純粋に関数型の言語は、不変であり、関数型プログラミングのステートレススタイルによく適合するため、永続的なデータ構造の恩恵を受けます。 ただし、Javaのような（状態ベース、OOP）言語の永続データ構造のライブラリが時々見られます。永続的なデータ構造を支持してよく聞かれる主張は、不変であるためスレッドセーフであるということです。 ただし、永続データ構造がスレッドセーフである理由は、1つのスレッドが永続コレクションに要素を「追加」すると、操作は元の要素に要素が追加された新しいコレクションを返すためです。したがって、他のスレッドは元のコレクションを参照します。もちろん、2つのコレクションは多くの内部状態を共有しています。そのため、これらの永続的な構造は効率的です。 しかし、スレッドごとにデータの状態が異なるため、永続データ構造だけでは、あるスレッドが他のスレッドに見える変更を行うシナリオを処理するのに十分ではないように思われます。このためには、アトム、リファレンス、ソフトウェアトランザクションメモリ、またはクラシックロックや同期メカニズムなどのデバイスを使用する必要があるようです。 それでは、なぜPDSの不変性が「スレッドセーフ」にとって有益であると宣伝されているのでしょうか。PDSが同期、または並行性の問題の解決に役立つ実際の例はありますか？または、PDSは、関数型プログラミングスタイルをサポートするオブジェクトへのステートレスインターフェイスを提供する単なる方法ですか？

17 functional-programming  data-structures  multithreading  concurrency