問題タブ [shared-state]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
java - Java EE サーバー間でデータを共有する
次のシナリオでは、どの製品/プロジェクトが役に立ちますか?
- 複数のサーバー (同じ場所)
- 一部の状態はサーバー間で共有する必要があります (たとえば、スケジュールされたタスクが実行されているかどうか、どのサーバーで実行されているかなどの情報)。
明白な答えはもちろんデータベースかもしれませんが、私たちは Seam を使用しており、Seam-bean 内にトランザクションをネストする良い方法がないように思われるので、構成に夢中になる必要がない方法を見つける必要があります。 (EJB:s を使用しようとしましたが、persistence.xml は後できれいではありませんでした)。したがって、Seam がネストされたトランザクションをサポートするまで、この問題を回避する別の方法が必要です。
これは基本的に、詳細が必要な場合のシナリオと同じです: https://community.jboss.org/thread/182126。
何か案は?
python - PythonでManagers()を使用して複数のプロセス間で文字列を共有する方法は?
メイン プロセスから multiprocessing.Process インスタンスによって書き込まれた文字列を読み取る必要があります。私はすでにマネージャーとキューを使用して引数をプロセスに渡しているため、マネージャーの使用は明らかですが、マネージャーは文字列をサポートしていません。
Manager() によって返されるマネージャーは、list、dict、Namespace、Lock、RLock、Semaphore、BoundedSemaphore、Condition、Event、Queue、Value、および Array の型をサポートします。
マルチプロセッシング モジュールのマネージャーを使用して、文字列で表される状態を共有するにはどうすればよいですか?
websocket - 多対多のストリーミングによる共有状態の設計パターン
複数のユーザーが同じホワイトボードを表示して描画できる、楽しみのためにオンライン ホワイトボード アプリケーションを作成しています。私は websockets (フロントエンドにバニラ JS、バックエンドに Scala) を使用しています。現在、基本的には、あるユーザーから残りのユーザーにマウス イベントをブロードキャストし、画像をクライアント側でレンダリングしています。
ただし、これにより一時的な共有状態が発生しますが、ユーザーがいつでもホップして、保存された共有状態を確認できるようにしたいと考えています。これには、おそらくバックエンドとフロントエンドでレンダリング コードを共有する必要があると考えています。これにより、クライアントはストリーミング時にイベントをレンダリングしますが、クライアントが関連付けられたときにサーバーは生の画像データを送信できます。
ここで私の質問は次のとおりです。この種のプロジェクトで知っておくべき他の設計パターンは何ですか? これは楽しみ/学習プロジェクトであるため、これは自由回答形式の質問ですが、この種のデータ フローに関するいくつかの有用な参照を含む回答を受け入れます。
multithreading - ミューテックスを保持しているときに pthread_create を呼び出しても安全ですか?
共有状態にアクセスしているときにミューテックスを保持しているコードがあるとします。ある時点で、新しいスレッドを作成する必要があると判断し、ミューテックスを保持したまま pthread_create を呼び出します。これは安全と考えられますか?
共有状態が、正常に作成された pthread の数を追跡するグローバル カウンターであり、別のスレッドがこのカウンターを使用して情報を画面にライブで表示するとします。さらに、pthreads の数が特定の最大値 (明確にするために 10 とします) よりも大きくならないようにします。
カウンターが現在 9 であるとします。カウンターをインクリメントしてから、pthread_create を呼び出す前にミューテックスを解放すると、pthread_create が失敗する可能性があり、実際に正常に作成されたよりも多くのスレッド (10) がカウンターに誤って表示されます ( 9)。
一方、最初にミューテックスを解放し、次に pthread_create を呼び出し、呼び出しが成功した場合にカウンターをインクリメントするためにミューテックスを再取得した場合、ミューテックスを解放してから pthread_create から戻るまでの間に、別のスレッドが pthread_create を呼び出した可能性もあります。カウンターをインクリメントしました(10に)。したがって、11 番目の pthread を作成したことになり、カウンターは 11 になります。
したがって、共有状態の一貫性を保証する唯一の方法は、pthread_create を呼び出している間にミューテックスを保持することです。しかし、一般に、ミューテックスを保持している間に未知のコードを呼び出すべきではないことを認識しているため、そのような場合に何ができるかわかりません。
編集:これは、この問題が発生するサンプルコードです
android - Android + CustomView: ネットワークの応答を待っている間にカスタム ビューの状態を共有する
次のシナリオがあります。
- アクティビティには 2 つのフラグメントがあります。
- 各フラグメントにはカスタム ビュー (同じだが異なるインスタンス) があります。
- 1 つのフラグメント アルゴは DialogFragment を呼び出してビューのサイズが全画面表示になるのをエミュレートするため、同じカスタム ビューがもう 1 つあります。
カスタム ビューのいずれかをクリックすると、ネットワーク リクエストが作成され、応答が完了するまで (スピナーを使用して) 待機します。私の問題は、ビューの状態を「共有」したいということです。そのため、カスタム ビューのいずれかをクリックすると、3 つのビューにスピナーが表示され、すべてのビューが応答を待機し、応答が到着したときにそれらのすべてが各スピナーを削除し、カスタム ビューに再びアクセスできるようにします。