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

私は次のシナリオを持っています： ユーザーがETagに対してGETリクエストを/projects/1行い、ETagを受け取ります。 ユーザーは、ステップ1のETag を使用してPUTリクエストを/projects/1行います。 ユーザーは/projects/1、ステップ1のETag を使用して別のPUTリクエストを行います。 ETagが古くなっているため、通常、2番目のPUTリクエストは412応答を受け取ります。最初のPUTリクエストがリソースを変更したため、ETagは一致しなくなりました。 しかし、2つのPUT要求が同時に（またはちょうど1つずつ）送信された場合はどうなりますか？最初のPUT要求には、PUT＃2が到着する前にリソースを処理および更新する時間がないため、PUT＃2がPUT＃1を上書きします。楽観的ロックの要点は、それが起こらないようにすることです...

11 rest  language-agnostic  concurrency  http 

同時実行の問題で立ち往生しています。 ユーザーが2から3のトランザクションを送信して、DBで重複してはならないデータを永続化するという典型的な問題です。重複するレコードがある場合、エラーを返す必要があります。 この問題は、ハッシュを格納する列にインデックス（一意）を追加できる場合は簡単です。 しかし、この場合、巨大なテーブル（おそらく数百万のレコード）があり、テーブルを変更することはできません。 実際、重複してはならないデータのハッシュを格納する列がありますが、一意のインデックスは設定されていません。 フラッシュの直前にJavaコードが存在するかどうかを確認しようとしていますが、それでも重複が発生します。 これに対する私の可能な解決策は次のとおりです。 挿入しようとしているハッシュがテーブルに既に存在するかどうかをチェックするトリガーを作成します。 このテーブルの一意のインデックスを格納する別のテーブルを作成し、メインテーブルに外部キーを追加します。 胎児の位置に座り泣く

10 database  concurrency 

私が読んでてきたブライアン・ゲッツにより、実際にJavaの並行処理を し、セクション内のスタック閉じ込め、各スレッドは独自のスタックを取得し、そのローカル変数は、本質的に実行中のスレッドに限られていることを述べています。これらは実行中のスレッドスタックに存在し、他のスレッドからはアクセスできません。各スレッドが独自の実行スタックを持っているとはどういう意味ですか？

10 java  multithreading  concurrency  stack 

C＃の分散システム用のカスタム再帰オブジェクトロックメカニズム\パターンを考え出す必要があります。基本的に、私はマルチノードシステムを使用しています。各ノードは、n個の状態に対して排他的な書き込み権限を持っています。同じ状態が、少なくとも1つの他のノードで読み取り専用形式でも利用できます。一部の書き込み/更新はすべてのノードでアトミックである必要がありますが、他の更新はバックグラウンドのレプリケーションプロセスやキューなどを通じて最終的に整合性が取れます... アトミック更新では、オブジェクトを書き込み用にロックされているものとして効率的にマークして、配布、コミット、ロールバックなどを実行できるパターンまたはサンプルを探しています。システムには高レベルの同時実行性があるため、ロックが解除されるとタイムアウトになるか、アンロールされるロックをスタックできるようにする必要があると思います。 トランザクションまたはメッセージングの部分はこの質問の焦点では​​ありませんが、いくつかの追加のコンテキストのためにそれらを提供しました。とはいえ、必要に応じてどのようなメッセージが必要だと思うかを自由に説明してください。 これは、私が想像していたものの漠然としたサンプルですが、まったく新しい製品を実装することを除いて、新しいアイデアを受け入れることができます。 thing.AquireLock(LockLevel.Write); //Do work thing.ReleaseLock(); 次のような拡張メソッドの使用を考えていました public static void AquireLock(this IThing instance, TupleLockLevel lockLevel) { //TODO: Add aquisition wait, retry, recursion count, timeout support, etc... //TODO: Disallow read lock requests if the 'thing' is already write locked //TODO: Throw exception when aquisition fails instance.Lock = lockLevel; } …

10 c#  multithreading  concurrency  distributed-development 

私は、必死にそれを必要とするIDEを拡張するCOMアドインを書いています。関係する機能はたくさんありますが、この投稿のために2つに絞ってみましょう。 ユーザーがモジュールとそのメンバーをナビゲートできるツリービューを表示するコードエクスプローラーツールウィンドウがあります。 ユーザーがコードの問題をナビゲートして自動的に修正できるようにするdatagridviewを表示するコードインスペクションツールウィンドウがあります。 どちらのツールにも、開いているすべてのプロジェクトのすべてのコードを解析する非同期タスクを開始する「更新」ボタンがあります。コードエクスプローラは、構築するために、解析結果を使用してツリービューをし、コード検査は、コードの問題を発見し、その中で結果を表示する解析結果を使用するDataGridView。 ここで私がやろうとしているのは、機能間で解析結果を共有することです。これにより、コードエクスプローラーが更新されたときに、コードインスペクションがそれを認識し、コードエクスプローラーが行った解析作業をやり直すことなく更新できるようになります。。 それで私がやったことは、パーサークラスを、機能が登録できるイベントプロバイダーにしたことです。 private void _parser_ParseCompleted(object sender, ParseCompletedEventArgs e) { Control.Invoke((MethodInvoker) delegate { Control.SolutionTree.Nodes.Clear(); foreach (var result in e.ParseResults) { var node = new TreeNode(result.Project.Name); node.ImageKey = "Hourglass"; node.SelectedImageKey = node.ImageKey; AddProjectNodes(result, node); Control.SolutionTree.Nodes.Add(node); } Control.EnableRefresh(); }); } private void _parser_ParseStarted(object sender, ParseStartedEventArgs e) { Control.Invoke((MethodInvoker) delegate …

9 concurrency  user-interface  user-experience  asynchronous-programming 

私は、データを生成してサーバーに送信するモバイルデバイス（アプリケーションが埋め込まれている）からのビジネスデータを同期するシステムを設計しています。同期される各行は、データベースに特定のビジネスログを生成します。 同期するデータによって、ビジネスデータの最終変更日よりも古い日付（同期データ内）のデータが生成された場合、それを無視して、ログをデータベースに追加するだけです。アップロードされたデータが処理されると、データベースからデータがフェッチされ、デバイスにダウンロードされます。 書き込み直後のこのダウンロードのため、同期は同期でなければなりません。このような何かが私の既存のソリューションを置き換えるのに十分な価値がある場合は、まだリーダー/ライターのパターンを持つことが可能です。より重要なことは、最新のデータをダウンロードできることです。そのデータは全体としてフェッチされ、現時点では差分は実装されていません（後で来る可能性がありますが、問題はありません）。 同じビジネスオブジェクトで複数の同期を実行している可能性があります。それは起こりそうにありませんが、起こり得、それを処理できることを望んでいます。組み込みモバイルアプリケーションを数日間再同期せずに使用しない限り、同期は数秒続くことが予想されますが、数分は続きません。 同期されるデータの量は、同期プロセスも大きくなることは想定されていません。 つまり、同期の方法で相互排除を使用することになります。より正確には、Javaを使用し、読み取り専用の同期をブロックしないように、同期プロセス全体ではなく、書き込みメソッドに同期を設定します。 私が知りたいのですが ： この方法が理にかなっていますか？同期プロセスの量と時間は許容範囲です。 一般的に、どのような概念を検討する必要がありますか。おまけ：Springモジュールにこれらの概念の実装がある場合。

9 java  concurrency  spring  synchronization 

私はアッカと俳優のフレームワークに不慣れです-明らかな何かが欠けていると確信しています。事前に謝罪を受け入れてください。 私は、Akkaを選択する際の主なポイントの1つが、並行性の管理方法であることを読み続けています。 Akkaがなぜそれほど特別なのかははっきりしません。私は非常に軽くて速い小さな俳優がたくさんいることを理解しています。ただし、2人のユーザーが同時にフォームを保存する場合、これはどのように役立ちますか？ なんらかの並行処理ロック（悲観的/楽観的/その他）はまだ必要ないのでしょうか？

9 concurrency  locks  actor-model  akka 

環境 RESTアーキテクチャスタイルのステートレス性により、各リクエストは完全に独立しており、サーバーはクライアントに関する情報を決して保存しません。 したがって、どのクライアントがリソースのロックを取得するかをサーバーストアに要求するため、悲観的な同時実行制御は適していません。次に、Etagヘッダーを使用して、オプティミスティック並行性制御が使用されます。（ところで、私がそこに尋ねたように/programming/30080634/concurrency-in-a-rest-api） 問題 楽観的同時実行制御メカニズムの主な問題は、すべてのクライアントがいつでも任意の操作を実行できるようにすることです。 そして、RESTの無国籍原則を破ることなく、それを回避したいと思います。つまり、すべてのクライアントがいつでも操作を実行することはできません。 質問 私の考えでは、次のような準楽観的同時実行制御メカニズムで可能です。 クライアントはトークンを要求できます 生成できるトークンは1つだけで、有効期間は限られています リソース（POSTやPUTなど）で操作を実行するには、クライアントはこのトークンをリクエストの本文（またはヘッダー？）の一部として渡す必要があります。トークンを持たないクライアントは、これらの操作を実行できません。 これは、楽観的同時実行制御に非常に似ていますが、「すべてのクライアントがすべての操作を実行できる」とは逆に、1つのクライアントのみが一部の操作（トークンを取得したクライアント）を実行できる点が異なります。 このメカニズムはRESTアーキテクチャスタイルと互換性がありますか？それはその制約のいずれかを破りますか？私はSOについて質問することを考えていましたが、これはソフトウェア設計に関連する、よりハイレベルな質問のようです。

9 design  architecture  rest  concurrency 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 6年前休業。 アクターの同時実行モデルは明らかに支持を得ています。モデルのパターンと落とし穴を示す良い本はありますか？私は、例えば、数百または数千の独立した俳優の文脈における一貫性と正しさの問題を議論するようなことを考えています。 特定の言語（Erlang、それは一般にアクターの実証済み実装とみなされているように思われるので、想像できると思います）に関連付けられていても問題ありませんが、1つか2つの紹介章以上のものを期待しています。Scalaで実装されているアクターには、そのようなリソースが利用可能であれば、私は実際に最も興味があります。

9 concurrency  actor-model 

過去1年間、私はJavaの並行処理に多くの取り組みをしており、多くの並行パッケージを構築して取り組んできました。並行世界の発展という点では、私は非常に自信があります。さらに、並行プログラミングについてもっと学び、理解することに非常に興味があります。 しかし、私は次の自分に答えることができませんか？マルチコアプロセッシングに関連するスキルをさらに引き継ぐために、何を追加で学習または取り組む必要がありますか。次のレベルに進むことができるように、マルチコア処理に関連する素敵な本（「実際の並行性」と「Javaでの並行プログラミング」を読んで楽しんだ）またはリソースがある場合は？

9 concurrency  multi-core 

私はScalaがJavaよりも並行性をうまく処理するという記事を読みました。 http://www.theserverside.com/feature/Solving-the-Scalability-Paradox-with-Scala-Clojure-and-Groovy ...スケーラビリティの制限は、特にJavaプログラミング言語自体に限定されますが、Javaプラットフォーム全体の制限ではありません... Javaのスケーラビリティの問題は新しい発見ではありません。実際、これらの問題に対処するために多くの作業が行われ、最も成功したプロジェクトの2つはScalaとClojureという名前のプログラミング言語です... ... Scalaは、Java言語の問題のあるスレッドとロックパラダイムを回避する方法を見つけています... これはどのようにして可能ですか？Scalaは、JavaからScalaにすべてのスレッドとロックの問題をもたらすJavaのコアライブラリを使用していませんか？

9 java  scala  concurrency  scalability 

SoftwareとConcurrency Revolution（htmlバージョン）という名前の並行性に関する研究論文を読んでいたとき。私は次の行に出くわしました： 残念ながら、ロックは機能しますが、最新のソフトウェア開発にとって深刻な問題を引き起こします。ロックの基本的な問題は、ロックが構成可能でないことです。正しいロックベースのコードを2つ取り、それらを組み合わせて、結果がまだ正しいことを知ることはできません。現代のソフトウェア開発は、ライブラリをより大きなプログラムに構成する機能に依存しているため、ロックベースのコンポーネントを、その実装を調査せずに構築することは困難です。 私は、Javaがどのように構成可能な同時実行性を保証するか、あるいはこのシナリオを生成する方法があるかさえ考えていました。 また、1つ以上のライブラリのデータをどのように同期させることができますか？プログラマーは自分のプログラムからそれを行うことができますか、それとも物事を同期させるのはライブラリ次第です。 Javaでない場合、ロックベースの同時実行を使用し、構成可能な同時実行を保証する他の言語はありますか？ 以下も同じ論文から引用したものです。 同期メソッドには少なくとも3つの大きな問題があります。1つは、他のオブジェクト（Javaのベクターや.NETのSyncHashTableなど）の仮想関数を呼び出すメソッドを持つ型には適していません。ロックを保持したままサードパーティのコードを呼び出すと、デッドロックが発生する可能性があるためです。第2に、同期されたメソッドは、すべてのオブジェクトインスタンスのロックを取得および解放することにより、多くのロックを実行する可能性があります。第3に、プログラムがオブジェクトまたは異なるオブジェクトに対して複数のメソッドを呼び出すときに原子性を維持しないため、同期化されたメソッドはロックをほとんど実行できません。後者の簡単な例として、銀行振込を考えてみましょう。account1.Credit（amount）; account2.Debit（amount）... 注：論文は2005年9月に発行されました

8 java  programming-languages  concurrency  locks 

だから私はGoingNative 2012：誰もが質問できるインタラクティブパネルでこれらすべてのC ++マスターと共にYoutubeでこのビデオを見ました。 これは私が話していたビデオです：GoingNative 2012-1日目-インタラクティブパネル：ネイティブであることの重要性 そして時間0:24:00に誰かが非常に興味深い質問をしました： 私たちはしばらくの間、pthreadを使用したり、Windowsスレッドを使用したりして並行プログラミングを行ってきました。C++とCが並行プログラミングに追いついてうれしいですが、すでに5年または10年遅れているように思えます何年もの間、現在、これらの強力なマルチコアがすべてあり、これらのマルチコアのプログラミングはスレッドに基づくべきではなく、タスクベースである必要があり[...]、MicrosoftにはPPLライブラリなどがあり、これは完全にC ++標準には反映されていません。[...]私が恐れている唯一のことは、標準がスレッドにロックされ、タスクベースのプログラミングに移行するのが非常に困難になることです... 今、私はこれらの概念にかなり慣れていないので、少し混乱しています。実際にタスクベースのプログラミングとは何ですか。この用語は、ロックフリープログラミングと同じ意味ですか？これらの2つの同等の用語ですか、それらの間にリンクはありますか？

8 c++  multithreading  concurrency  c++11  multi-core 

最適化が早すぎないという原則に従って、ソフトウェアの設計/開発のどの時点で、同時実行の機会について考え始めますか？ シングルスレッドのアプリケーションを作成し、プロファイリングを通じて、並列実行の候補となるセクションを特定することが1つの戦略となることはよく想像できます。私が少し見てきたもう1つの戦略は、タスクのグループごとにソフトウェアを検討し、独立したタスクを並列化することです。 もちろん、尋ねる理由の1つは、最後まで待ってソフトウェアをリファクタリングするだけで同時に動作する場合、可能な限り最悪の方法で構造化し、大きなタスクを抱えることになるということです。 設計で並列化を検討するときに、どのような経験が役立ちましたか？

8 development-process  multithreading  concurrency  parallelism 

さて、私は今日これについて考えていました、そして私はそれについて完全に主観的でバイアスのある意見を求めるようになりました。逆説的に、これにもかかわらず、私はそれが炎戦の飼料でもないと思います。完全に文明化された会話の余地はあると思います-Vim対Emacsはほとんどありません。 私は多くの並行処理の抽象化、特にスレッドの上に構築されたものを使用しました。メッセージパッシング、デフォルトでは不変、デフォルトではスレッドローカル、その他のいずれでも、それらの間には大きな傾向があります。 トレンドは、データ共有を暗黙的ではなく明示的にすることで、スレッドの考え方を逆転させているというものです。つまり、特に指定しない限り、すべてのデータは共有されません。これは、Javaなどの言語で見られる従来のスレッド化とは逆です。（ただし、Javaは独自の高レベルの同時実行抽象化をサポートしていることを知っています。）たとえば、メッセージを明示的に渡します。どの変数がスレッドローカルであるかを明示的に指定します。変更可能な変数を明示的に指定します。これらは、いくつかの言語で見られるほんの一例です。 この並行性の簡単なスタイルは現代のコンセプトだと思いました。間違えた。最近fork（）やpipe（）のようなUNIXのおもちゃをいじり始めましたが、UNIXの開始以来、簡単で明示的な並行処理メカニズムが存在していることを知ってショックを受けました。 70年代のC + UNIXが同時実行性を多くの最新のトレンディなスレッド化メカニズムよりもはるかに簡単にすることを実現することには、少し奇妙な点があります。 だから、ここで私が疑問に思っているのは...これらの現代のスレッド抽象化は、すべての明示性とデフォルトで共有されない特性を備えたスレッド上でUNIXスタイルのプロセスを単にエミュレートしようとしているのでしょうか？STMのようないくつかのメカニズムがDBスタイルのトランザクションのようなものを提供することは確かですが、それは本当に並行性のための現代的で革新的なソリューションですが、ほとんどの場合、UNIXプログラマーが昔行っていたことを行う新しい方法のように見えます。 言うまでもなく、私はUNIXのファンではなく、想像力を伸ばしているわけでもありません。プロセスは多くのプラットフォームで初期化するためにスレッドよりもはるかに遅いことを認識していますが、これは概念的に述べています。

8 performance  multithreading  concurrency