問題タブ [mutex]

基本クラス Token があります。これには実装がなく、マーカー インターフェイスとして機能します。これは、呼び出し元が使用する型です。

派生クラス LockToken があります。これはミューテックスをラップし、構築中にロックが取得され、破棄中に解放されることを保証します。startJob メソッドは、トークン (ロックを提供しない) または LockToken (ロックを提供する) を返すかどうかを決定するという意味で、ファクトリ メソッドです。

startJob が基本インスタンス (トークン) を返す場合、すべてがうまく機能します。それ以外の場合 (jobId>0)、派生インスタンスからベース インスタンスへのコピーが作成されます。他のワークでは、別のトークンが LockToken からコピー構築され、元の LockToken があまりにも早くスコープから外れ、startJob のスコープ内でロックが解放されます。

どうすればこの問題を解決できますか? startJob を変更して、真の共変トークン (LockToken である可能性があることを意味する) を返すか出力することはできますか?

プロセス間通信を実装するアプリケーションを作成しています。この目的のために、私は共有バッファを設定しました。これは正常に機能しているようです。ここで、データ生成アプリケーション (c++ で記述) がデータ受信アプリケーション (freepascal/lazarus で記述) にいつデータを読み取る必要があるかを伝える方法が必要です。

この目的のためにミューテックスを使用しようとしていました。Windows API プログラミングの経験はあまりありません。

したがって、私の問題は、以下の FreePascal コードでは、ミューテックスが待機しないことです。TMutex.Wait() 関数を呼び出すことができます。エラーなどは返されませんが、単に待機しません。

コンストラクタ TMutex.Create(sName: AnsiString);
sNameを開始し
  ます:= 'Local\Mutex'+sName;
  hMutex := CreateMutexA(
        nil, // デフォルト アクセス
        True, // 最初は所有されていない
        PChar(sName)); // 名前付きミューテックス
  hMutex = 0 の場合は、例外の発生を
  開始します。Create
    ('mutex の作成に失敗しました');
  終わり;
終わり;

デストラクタ TMutex.Destroy;   CloseHandle(hMutex)
を開始します。 終わり; 手順 TMutex.Wait; begin   if (WaitForSingleObject(hMutex, INFINITE) <> 0) then ShowMessage('debug: 何かが返されるのを待つ'); 終わり;








手順 TMutex.Post;   ReleaseMutex(hMutex)
を開始します。 終わり;

ロックフリーのデータ構造が「特定のワークロードに対して」より効率的であることをどこかで読みました（もうページが見つかりません）。アトミック操作を実行するためのロック命令の約 100 サイクルのヒットは、スリープしてスケジューラがプロセスを復帰させるのを待つよりもはるかに高速に聞こえるため、ロックフリーのデータ構造がどのような状況下にあるかは明らかではありません。昔ながらのミューテックスよりも好ましくないでしょう。ロックが 99% の時間利用可能で、プロセスがスリープ状態になる必要がない場合、ミューテックスの方が高速ですか? 適切なロックのないデータ構造が利用可能であると仮定して、どちらに進むべきかを知るための良い経験則はありますか?

複雑なデータ構造をメモリ（キャッシュデータ）に保持するマルチスレッドC++アプリケーションがあります。

データを読んでいる間は、すべてが素晴らしいです。データにアクセスしたい数のスレッドを持つことができます。

ただし、キャッシュされた構造は静的ではありません。

• 要求されたデータ項目が利用できない場合は、データベースから読み取られ、データツリーに挿入されます。これもおそらく問題ではなく、新しいデータ項目をツリーに追加するときにミューテックスを使用しても、数サイクルしかかかりません（ポインターを追加するだけです）。
• 時々実行されるガベージコレクションプロセスがあります。ツリーからすべての古いアイテムを削除します。そのためには、メモリから削除されるデータに他のプロセスが現在アクセスしていないことを確認するために、すべてをロックダウンする必要があります。また、キャッシュから読み取る間はツリーをロックして、処理中にアイテムを削除しないようにする必要があります（「逆の場合も同じ」のようなものです）。

「擬似コード」：

気になること：これは、読んでいる間はツリーをロックする必要があることを意味します（読んでいる間にガベージコレクションが開始されないようにするため）。ただし、副作用として、2つの読み取りプロセスを同時に実行することもできなくなりました。

助言がありますか？

「これは書き込みとのみ衝突する読み取り専用アクション」Mutexのようなものはありますか？

読み取り、書き込み、保留中の読み取り、保留中の書き込みカウンターを保持するマルチ R/W ロック クラスがあります。ミューテックスは、それらを複数のスレッドから保護します。

私の質問は、コンパイラーが最適化の実行中にカウンターを台無しにしないように、カウンターを揮発性として宣言する必要がありますか?

または、コンパイラは、カウンターがミューテックスによって保護されていることを考慮していますか。

ミューテックスは同期のための実行時のメカニズムであり、「volatile」キーワードは、最適化を行いながら正しいことを行うためのコンパイラへのコンパイル時の指示であることを理解しています。

よろしく、 -ジェイ。

BeOS プログラマーだった頃、 Benoit Schillings によるこの記事を読み、「ベナフォア」を作成する方法を説明しました: アトミック変数を使用して、共通のミューテックスを取得/解放する必要を回避するクリティカル セクションを強制する方法 (競合なし) ケース。

私はそれがかなり賢いと思いました.atomic-increment/decrementをサポートするどのプラットフォームでも同じトリックを行うことができるようです.

一方、これは標準のミューテックス実装自体に簡単に含めることができるもののように見えます...その場合、私のプログラムでこのロジックを実装することは冗長であり、何の利点もありません.

最新のロック API (pthread_mutex_lock()/pthread_mutex_unlock() など) がこのトリックを内部的に使用しているかどうかを知っている人はいますか? もしそうでなければ、なぜですか？

スレッド A に次のコードがあります。pthread_cond_wait()

スレッドBに次のコードがあり、スレッドAに通知します

他にスレッドがない場合、pthread_cond_signal(&my_wait)以下に示すようにクリティカル セクション ブロックの外に移動しても違いはありますか?

ネット上のあちこちで何度も読んだことがあるので、ミューテックスはクリティカルセクション/セマフォ/insert-your-preferred-synchronisation-method-hereよりも低速です。しかし、私はこの主張を裏付ける論文や研究などを見たことがありません。

それで、このアイデアはどこから来たのですか？それは神話ですか、それとも現実ですか？ミューテックスは本当に遅いですか？

ネットワーク上で実行されるデスクトップ アプリケーションがあり、すべてのインスタンスが同じデータベースに接続しています。

では、この状況で、同じデータベースに接続されている実行中のすべてのインスタンスで機能するミューテックスを実装するにはどうすればよいでしょうか?

言い換えれば、2 つ以上のインスタンスで同じ関数を同時に実行したくありません。1 つの関数が既に実行されている場合、他のインスタンスはその関数にアクセスできません。

PS: ミューテックスしたくない関数がデータベースを使用しないため、データベース トランザクションは解決しません。データベースについて言及したのは、実行中のインスタンス間で情報を交換するために使用できるからです。

PS2: 関数が完了するまでに約 30 分かかるため、2 番目のインスタンスが同じ関数を実行しようとした場合、コンピューター 'X' が既にその関数を実行しているため、現在実行できないというメッセージを表示したいと考えています。 .

PS3: 関数はクライアント マシンで処理する必要があるため、ストアド プロシージャを使用できません。