4

私は常にファイルを 2 つの方法で開いてきました。つまり、読み取りアクセスと共有読み取り、または読み取り/書き込みアクセスと非共有のいずれかです。

私には、共有書き込みを許可すると、ファイルの読み取り中にファイルに予期しないことが常に発生する可能性があるようです。共有書き込みモードでファイルを開く正当な理由はありますか?

4

3 に答える 3

2

ファイルが多くのプロセスで共有されている場合、（パフォーマンス上の理由から）ファイル全体をロックすることが実際的でない場合があります。

この場合、書き込み中にファイルの領域をロックできます。

Windowsでは、関数LockFile（）を使用できます。
Linux / Unixでは、fcntl（）またはflock（）を使用できます。

于 2009-06-06T02:08:15.360 に答える
1

ファイルI/Oより低いレベルのソケット。

サーバーがいくつかのローカルポート1999でリッスンし、サービスポート3128ですべてのサブスクライブしているクライアントにインバウンドを中継するとします。

サーバーは、複数のローカルクライアントから読み取り、複数のリモートクライアントに中継することができます。サーバーが認証デーモンである場合、複数のローカルアプリケーションが同じサーバー（サービス）を介して認証を試みる可能性があります。ユーザーが認証サーバーを共有するアプリの1つに正常にログインしたため、ユーザーxが認証されたことをリモートクライアントに通知できます。

何を言っているのかわかりません。私は推測を試みています。

于 2009-06-06T01:54:08.277 に答える
1

私は推測を危険にさらします...それが使用される可能性のあるものの1つは、並列計算です。高度に並列化可能な計算を実行する 2 つのスレッドがあり、データを 1 つのファイルに書き込む必要があるとします。また、各スレッドの出力を格納するために必要なサイズ (たとえば 50MB) を事前に決定することもできます。

したがって、100MB のファイルを割り当て、スレッド 1 がオフセット 0 で書き込みを開始し、スレッド #2 が 50MB で開始するようにします。スレッドが完了すると、単一の構成済みファイルが作成されます (それ以外の場合は、別のファイルを使用して、スレッド #2 の結果をスレッド #1 に追加する必要があります)。

アスキーアートの試み

 ==============================  
|      50MB    |     50MB      |   [100 MB Total FileSize]
|              |               |  
 ==============================  
^               ^
|               |
Thread 1        Thread 2

とは言っても、私はこれをやったことがありません。うまくいかないかもしれません！おそらく、他の同期メカニズムを使用してスレッド間でファイルハンドル/ストリームを共有することもできますが、各スレッドのオフセットもリセットする必要があります。おそらく、どちらか一方がより効率的です。

一方では、両方のスレッドが常に同時に書き込みを行っている場合、大量のディスク スラッシングが発生する可能性があります。逆に、書き込みロックで多くの競合が発生している場合、書き込みを同期すると、同時実行の利点が失われる可能性があります。よく言われるように、プロファイリングとテストを行います。

とにかく、私は共有書き込みアクセスが使用されている「実際の」シナリオにも興味があり、さらに回答を待ちます!

于 2009-06-06T01:44:52.677 に答える