2

ブーストファイルロック（共有可能およびスコープ付きのfile_locks）の一般的な戦略、および一般的なファイルロックは次のとおりです。

  1. 開いた
  2. ロック
  3. ファイルの内容を操作する
  4. ロックを解除
  5. ファイルを閉じる

ただし、追加用にファイルを開き、tellp を呼び出して現在の場所を確認したいと考えています。上記のシナリオでこれを行うのは安全ですか? ロックの前にファイルが開かれるとすぐにファイルポインタが設定され、保護されない可能性はありませんか? もしそうなら、これを回避するための標準的なイディオムはありますか?

4

2 に答える 2

1

これは環境固有の場合がありますが、ほとんどのプラットフォームでは次のようになります。

追加のためにファイルが開かれると、ファイルポインタはすべての書き込みの直前に調整されます。したがって、tellpファイルをロックする前に使用すると、新しく追加されたバイトがどこに行くのかがわからない可能性がありますが、ロックを使用して同じ範囲のバイトを追加している 2 つのプロセスを持つべきではありません。

于 2011-01-13T02:58:21.640 に答える
0

優れたブースト ドキュメントをお勧めします: http://www.boost.org/doc/libs/1_45_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.file_lock

あなたが読むことができる：

  • ファイル ロックは、オペレーティング システムがサポートしている場合でも、オペレーティング システムのロックではありません (たとえば、Windows ではサポートされていますが、Unix では通常はサポートされていません)。そのため、ファイルをロックすると、他のプロセスが同じファイル ロック メカニズムを使用しない限り、誰でもそのファイルを読み取り/書き込み/削除できます。したがって、実際のファイル ロックではなく、プロセス間ミューテックスのように考えてください。
  • ファイルロックはプロセス間同期用であり、プロセス内の複数のスレッドを同期しません
  • フラッシュ (ofstream のフラッシュ) を忘れないでください。バッファリングについて心配する必要はありません。

ああ、これはひどいです...助けたかったので、サンプルコードを書いて試してみました... 1_44の時点で、win32のファイルロックは壊れており、ロックされたファイルではフラッシュが機能しません。

申し訳ありませんが、私のせいではありません。

それが役立つ場合、理論的には、追加のためにファイルを開くと、すべての書き込み操作の前に自動シークが終了することを意味します。書き込みがなくても、いつでも手動で終了しようとするのを止めることはありません。ただし、経験 (上記参照) は次のように述べています。壊れたものから離れてください。

于 2011-01-13T07:51:56.057 に答える