file-io - 是否有任何理由打开具有共享写入访问权限的文件？

Question

我总是以两种方式打开我的文件——读取访问和共享读取，或者读/写访问和不共享。

在我看来，允许共享写入似乎总是会导致您在阅读文件时发生意外的事情。是否有充分的理由以共享写入模式打开文件？

Answer 1

如果一个文件由多个进程共享，有时锁定整个文件是不切实际的（出于性能原因）。

在这种情况下，您可以在写入文件时锁定文件的某个区域。

在 Windows 中，您可以使用函数LockFile()。
在 Linux/Unix 中，您可以使用fcntl()或flock()

Answer 2

我会冒险猜测......它可能用于并行计算的一件事。假设您有两个线程在执行一些高度可并行化的计算，并且您需要将数据写入单个文件。您还可以预先确定存储每个线程的输出所需的大小（例如 50MB）。

因此，分配一个 100MB 的文件，让线程 1 从偏移量 0 开始写入，线程 #2 从 50MB 开始。当线程完成时，您将拥有单个组合文件（否则，使用单独的文件，您需要将线程#2 的结果附加到线程#1）。

ASCII 艺术尝试

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

说了这么多，我从来没有这样做过。它甚至可能不起作用！可以想象，您可以使用其他一些同步机制在线程之间共享文件句柄/流，但是您还必须重置每个线程上的偏移量。也许其中一个更有效。

一方面，如果两个线程总是同时写入，可能会出现大量磁盘抖动。相反，如果写锁有很多争用，同步写操作可能会抵消并发的好处。正如常说的，配置文件和测试！

无论如何，我也对使用共享写访问的“现实生活”场景感到好奇，并将关注更多答案！

Answer 3

低于文件 I/O 级别的套接字。

假设服务器在某个本地端口 1999 上进行侦听，并将入站中继到服务端口 3128 上的所有订阅客户端。

服务器可以从多个本地客户端读取并中继到多个远程客户端。如果服务器是身份验证守护进程，则多个本地应用程序可能会尝试通过同一服务器（服务）进行身份验证。可以通知远程客户端 user-x 现在已通过身份验证，因为他/她已成功登录到共享身份验证服务器的应用程序之一。

我不知道我在说什么。我冒昧猜测。