問題タブ [synchronization]
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.
file - WindowsからLinuxサーバーにファイルを即座にミラーリング/同期する最良の方法
Windows マシン上に、監視する必要のある多数のファイルとフォルダーを含むディレクトリがあり、ファイルをローカル ネットワーク経由で Linux マシンに即座に (または可能な限り近い状態で) ミラーリング/同期します。
私は調査しました: - Rsync、リアルタイムでは不十分 - WinSCP の「ディレクトリを最新の状態に保つ」機能。
これを行うと主張するシェアウェア スタイルのアプリの結果はたくさんありますが、どれもかなり疑わしいものです。どこかに優れた FOSS ソリューションがあるはずですか?
更新: 即時かつ自動である限り、完全な同期ではなく一方向の転送に満足しています。
c# - 値を読み取るときにリソースをロックする必要がありますか?
C# でスレッド同期を行う場合、値を読み取ったり変更したりするときにオブジェクトをロックする必要がありますか?
たとえば、Queue<T> オブジェクトがあります。Enqueue と Dequeue を実行するときにロックするだけですか、それとも Count などの値をチェックするときにもロックする必要がありますか?
time - 分散時刻同期と Web アプリケーション
私は現在、サーバーとすべてのクライアント間で適切な時刻同期を本質的に必要とするアプリケーションを構築しようとしています。この同期の必要性をなくすことができる私のアプリケーション用の代替設計がありますが、私のアプリケーションは同期が存在しないとすぐに機能しなくなります。
何か不足している場合に備えて、私の基本的な問題は次のとおりです。複数の場所でまったく同時にイベントを発生させます。私が知る限り、これを行う唯一の方法はある種の時刻同期を必要としますが、私は間違っているかもしれません。問題を別の方法でモデル化しようとしましたが、すべて a) つまらないアプリ、または b) 時刻同期が必要です。
同期された時間が本当に本当に必要だと仮定しましょう。
私のアプリケーションは Google AppEngine で構築されています。AppEngine はサーバー間での時刻同期の状態について保証しませんが、通常は数秒程度 (つまり NTP よりも優れている) で非常に良好ですが、10 秒程度遅れる場合もあります。同期の。私のアプリケーションは 2 ~ 3 秒の同期のずれを処理できますが、ユーザー エクスペリエンスに関しては 10 秒は問題外です。基本的に、私が選択したサーバー プラットフォームは、信頼できる時間の概念を提供しません。
私のアプリケーションのクライアント部分は JavaScript で書かれています。ここでもまた、クライアントが信頼できる時間の概念を持っていない状況があります。私は測定を行っていませんが、私の最終的なユーザーの何人かは、1901 年、1970 年、2024 年などに設定されたコンピューターの時計を持っていることを完全に期待しています。基本的に、私のクライアント プラットフォームは信頼できる時間の概念を提供しません。
この問題は私を少し怒らせ始めています。これまでのところ、HTTP の上に NTP のようなものを実装するのが最善だと思います (これは思ったほどクレイジーではありません)。これは、インターネットのさまざまな場所に 2 つまたは 3 つのサーバーを設置し、従来の手段 (PTP、NTP) を使用して同期が少なくとも数百ミリ秒のオーダーであることを確認することで機能します。
次に、これらの HTTP 時刻ソース (および XMLHTTPRequest から入手できる関連するラウンドトリップ情報) を使用して、NTP 交差アルゴリズムを実装する JavaScript クラスを作成します。
お分かりのように、このソリューションも非常に時間がかかります。それは恐ろしく複雑であるだけでなく、問題の半分を解決するだけです。つまり、クライアントに現在の時間の適切な概念を与えることです。次に、サーバーで妥協する必要があります。クライアントが要求を行うときに、クライアントがサーバーに応じて現在の時刻を伝えることができるようにする必要があります (大きなセキュリティではありませんが、これのより明白な乱用のいくつかを軽減できます)。または、サーバーが魔法の HTTP-over-NTP サーバーの 1 つに単一の要求を作成し、その要求が十分に迅速に完了することを期待します。
これらの解決策はすべて最悪で、私は道に迷っています。
注意: Web ブラウザーの束 (できれば 100 以上) が、まったく同時にイベントを発生できるようにしたいと考えています。
algorithm - FIFO キューの同期
リーダーとライターが 1 つしかない場合、FIFO キューを同期する必要がありますか?
java - Javaで同期(これ)を避けますか?
synchronized(this)
Java同期についてSOに質問が出たときはいつでも、避けるべきだと非常に熱心に指摘する人もいます。代わりに、彼らは、プライベート参照のロックが優先されると主張しています。
与えられた理由のいくつかは次のとおりです。
- いくつかの邪悪なコードがあなたのロックを盗むかもしれません(これは非常に人気があり、「偶然に」バリアントもあります)
- 同じクラス内のすべての同期メソッドはまったく同じロックを使用するため、スループットが低下します
- あなたは(不必要に)あまりにも多くの情報を公開しています
私を含む他の人々は、これsynchronized(this)
は(Javaライブラリでも)頻繁に使用されるイディオムであり、安全でよく理解されていると主張しています。バグがあり、マルチスレッドプログラムで何が起こっているのか見当がつかないため、回避すべきではありません。言い換えれば、それが該当する場合は、それを使用します。
私はいくつかの実際の例(foobarのものはありません)を見ることに興味があります。そこでは、ロックオンを回避するthis
ことが望ましい場合synchronized(this)
もあります。
したがって、常に回避synchronized(this)
して、プライベート参照のロックに置き換える必要がありますか?
いくつかのさらなる情報(答えが与えられると更新されます):
- インスタンスの同期について話している
- の暗黙的(
synchronized
メソッド)と明示的形式のsynchronized(this)
両方が考慮されます - この件についてBlochまたは他の当局を引用する場合は、気に入らない部分を省略しないでください(たとえば、Effective Java、スレッドセーフの項目:通常はインスタンス自体のロックですが、例外があります)。
synchronized(this)
提供する以外のロックの粒度が必要な場合synchronized(this)
は適用されないため、問題にはなりません
windows - PostMessage でメッセージが失われることがある
マルチスレッド Windows アプリケーションを作成しました。ここで、スレッド:
A – ユーザーの操作を処理し、B からのデータを処理する Windows フォームです
。B – 時々データを生成し、2 つの A に渡します。
スレッド セーフ キューは、スレッド B から A にデータを渡すために使用されます。エンキューおよびデキュー機能は、Windows クリティカル セクション オブジェクトを使用して保護されます。
エンキュー関数が呼び出されたときにキューが空の場合、関数は PostMessage を使用して、キューにデータがあることを A に伝えます。この関数は、PostMessage への呼び出しが正常に実行されていることを確認し、成功していない場合は PostMessage を繰り返し呼び出します (PostMessage はまだ失敗していません)。
これは、ある特定のコンピューターが時折メッセージを失い始めるまで、かなり長い間うまくいきました。失うとは、PostMessage が B で正常に返されるが、A がメッセージを受信しないことを意味します。これにより、ソフトウェアがフリーズしたように見えます。
私はすでにいくつかの許容できる回避策を考え出しました。Windows がこれらのメッセージを失っている理由と、これが 1 台のコンピューターでのみ発生している理由を知るのは興味深いことです。
コードの関連部分を次に示します。
multithreading - 遅延読み込みのための HttpRuntime.Cache のロック
.NET 2.0 を実行している Web サイトがあり、ASP.Net HttpRuntime.Cache の使用を開始して、頻繁なデータ ルックアップの結果を保存し、データベース アクセスを削減しました。
スニペット:
キャッシュを見たいときはいつでも悲観的にロックしています。ただし、ロックのオーバーヘッドが発生しないように、代わりにキャッシュ値を確認した後にロックすることを提案するさまざまなブログが Web に投稿されているのを見てきました。チェック後に別のスレッドがキャッシュに書き込んだ可能性があるため、これは正しくないようです。
最後に私の質問は、これを行う「正しい」方法は何ですか? 正しいスレッド同期オブジェクトを使用していますか? ReaderWriterLockSlim() は認識していますが、.NET 2.0 を実行しています。
java - Prevayler の同期戦略とは?
Prevayler は、すべての書き込み (そのトランザクションを介して) が同期されることを保証します。しかし、読み取りはどうですか?
(ユーザー コードで) 明示的な同期が使用されていない場合、ダーティ リードが可能であるというのは正しいですか?
ビジネスオブジェクトが次のように読み取られる場合、それらは可能ですか。
?
もしそうなら、どの同期戦略がユーザーコードに適していますか?
(ビジネス オブジェクト A にビジネス オブジェクト B のコレクションが含まれているとします)、
- java.util.concurrent パッケージなどから (A 内の B の) 同期されたコレクションを使用しますか?
- トランザクション内のコレクションの書き込みとトランザクションの外部のコレクションの読み取りを同期します。