問題タブ [locking]

これを解決する最もエレガントな方法は何ですか:

• 読み取り用にファイルを開きますが、書き込み用にまだ開いていない場合に限ります
• 書き込み用にファイルを開きますが、まだ読み取りまたは書き込み用に開いていない場合に限ります

組み込み関数は次のように機能します

scr.txt に「111」が含まれるようになりました。

scr.txt は上書きされ、現在は「222」が含まれています (Windows では Python 2.4)。

このソリューションは、同じプロセス内 (上記の例のように) だけでなく、別のプロセスがファイルを開いたときにも機能するはずです。
クラッシュするプログラムがロックを開いたままにしない場合は、これをお勧めします。

POSIX では、mutex を再帰的にすることができます。これは、同じスレッドが同じミューテックスを 2 回ロックでき、デッドロックしないことを意味します。もちろん、ロックを 2 回解除する必要もあります。そうしないと、他のスレッドがミューテックスを取得できません。pthread をサポートするすべてのシステムが再帰的ミューテックスもサポートしているわけではありませんが、POSIX に準拠したい場合は、 .

他の API (より高レベルの API) も通常、ロックと呼ばれることが多いミューテックスを提供します。一部のシステム/言語 (Cocoa Objective-C など) は、再帰的ミューテックスと非再帰的ミューテックスの両方を提供します。一部の言語では、どちらか一方しか提供されません。たとえば、Java のミューテックスは常に再帰的です (同じスレッドが同じオブジェクトに対して 2 回「同期」する場合があります)。それらが提供する他のスレッド機能によっては、再帰的ミューテックスがなくても問題ないかもしれません。なぜなら、再帰的ミューテックスは自分で簡単に作成できるからです (より単純なミューテックス/条件操作に基づいて、再帰的ミューテックスを自分で実装しました)。

私がよく理解していないこと: 非再帰的ミューテックスは何に適していますか? 同じミューテックスを 2 回ロックすると、スレッドのデッドロックが必要になるのはなぜですか? それを回避できる高水準言語でさえ (たとえば、これがデッドロックするかどうかをテストし、デッドロックする場合は例外をスローする)、通常はそれを行いません。代わりに、スレッドをデッドロックさせます。

これは、誤って 2 回ロックして 1 回だけロックを解除した場合のみであり、再帰的ミューテックスの場合、問題を見つけるのが難しいため、代わりにすぐにデッドロックして、間違ったロックが表示される場所を確認しますか? しかし、ロックを解除するときにロック カウンターを返すことで同じことを行うことはできませんでした。最後のロックを解放し、カウンターがゼロではないことが確実な状況では、例外をスローしたり、問題をログに記録したりできませんか? または、私が見落としている非再帰的ミューテックスの他のより便利なユースケースはありますか? それとも、非再帰的ミューテックスは再帰的ミューテックスよりもわずかに高速になる可能性があるため、単なるパフォーマンスでしょうか? ただし、これをテストしたところ、違いはそれほど大きくありません。

私はcvsannotateを使おうとしています。これは私が実行するものです：

ただし、次のエラーが発生します。

これは何を意味するのでしょうか？どうすればこの問題を克服できますか？エラーメッセージに表示される^M文字に関連している可能性がありますか？

Eclipseを使用して注釈を付けると、機能します。チェックしたところ、ディレクトリ `/ mycvs / cvsroot / projects /dg'が存在します。このエラーは、rootとしてログインしているときにも発生するため、おそらくアクセス許可の問題でもありません。

CentOSを使用しています

Windows でファイル (.exe または .dll) を実行すると、ファイルがロックされ、削除、移動、または変更できないことに気付きました。

一方、Linux は実行中のファイルをロックせず、それらを削除、移動、または変更できます。

Linux がロックしないのに Windows がロックするのはなぜですか? ロックするメリットある？

私は現在、単純な CRUD アプリケーションに取り組んでいます。要件の 1 つは、ユーザーが同時に編集できないようにすることです。これを行うために、レコードを「ロック」して編集中かどうかを確認し、他のユーザーが同時に編集できないようにします。これを実装する良い方法は、AJAXキープアライブを使用してユーザーセッションの有効期限が切れているかどうかを確認し、そうであれば編集のためにレコードのロックを解除することだと考えていました。誰かがこのテクニックを以前に使用したことがありますか? ワークステーションが数分間ロックされていても機能しますか?

SQL Server 2000 で巨大なストアド プロシージャを実行するアプリケーションがあります。通常は完了するまでに約 1 分かかりますが、場合によってはそれ以上かかることもあります。たった今、テスト システムで 3 回連続して実行しました。1:12、1:23、55:25 かかりました。その行動の原因は何ですか？データベースでは他にも何かが起こっているので、ロックと関係があるのではないかと思います。どうすればこれを演技で捉えることができますか？

毎朝、AS400 / iSeries / i6（IBMが現在呼んでいるもの）のDB2に多数のクエリ（〜10000）を発行するプロセスがあります。過去2か月間、オペレーターは、クエリがいくつかのファイルをロックするという不満を持っています。彼らが毎晩の処理を完了するのを防ぎます。クエリは非常に単純です。

私は家のiSeries側の専門家ではなく、AS400/Db2の観点からロックのエスカレーションについて誰かが洞察を持っているかどうか疑問に思っていました。ロックの原因となっているIDは、リンクサーバーを登録したIDであることが確認されており、[Library]と[FileName]が発行しているクエリと一致しているため、最も可能性が高いことがわかります。

これは最近起こり始めたばかりです。AS400がロックをエスカレートする原因となっているselectステートメントは可能ですか？問題は、手動の介入なしではリリースされないことです。

レコードのロックに関して、私たちのチームに推奨される設計パターンを考え出そうとしています。典型的な考え方は次のようになります: 1. ユーザーがリストからレコードを選択する 2. ユーザー ID でレコードをロックする 3. ロックされたレコード レコードをロードする (ロックなしで、誰かがあなたを打ち負かす)。

何か不足していますか、それともこれが唯一の方法のように見えますか? ((私たちの場合、オプティミスティック ロックは、エンド ユーザーにとって面倒で混乱を招きます。多くの場合、編集は非常に重要です。))

java.uti.concurrent.locks.AbstractQueuedSynchronizer のソースコードを見ていましたが、acquire() メソッドは次のようになります -

acquire() を呼び出すスレッドを中断するのはなぜですか? スレッドの run() メソッドのどこかにチェックがあった場合、acquire() を呼び出した後に合格する可能性がありますが、これはおそらく望ましくなく、考えられていませんか?

上記のコードがこれを行う理由を明らかにしたい人はいますか?

別の Windows 2003 サーバーで実行されているプロセスによってロックされている Windows 2003 サーバー上のファイルがあります。このリソースをロックしているマシンのプロセスを見つけることは可能ですか。これを行うためにどの言語を使用してもかまいません。