是否有任何理由打开具有共享写入访问权限的文件？
我总是以两种方式打开文件——读取访问和共享读取，或者读/写访问但不共享。
在我看来，允许共享写入可能总是导致您在阅读文件时发生意外的事情。 在共享写入模式下打开文件有什么充分的理由吗？
I've always opened my files two ways -- either read access and shared-read, or read/write access and no sharing.
To me it seems that allowing shared-write could always result in unexpected things happening to the file while you're reading it. Are there any good reasons to open a file in shared-write mode?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果一个文件被许多进程共享，有时锁定整个文件是不切实际的（出于性能原因）。
在这种情况下，您可以在写入文件时锁定文件的某个区域。
在 Windows 中，您可以使用函数 LockFile().
在 Linux/Unix 中，您可以使用 fcntl() 或 flock()
If a file is shared by many processes, it is sometimes impractical to lock the whole file (for performance reasons).
In this case, you can lock a region of the file while it is being written.
In Windows you might use the function LockFile().
In Linux/Unix you might use fcntl() or flock()
我会冒险猜测......它可能用于并行计算。 假设您有两个线程正在执行一些高度并行化的计算，并且您需要将数据写入单个文件。 您还可以预先确定存储每个线程的输出所需的大小（例如 50MB）。
因此，分配一个 100MB 文件，让线程 1 从偏移量 0 开始写入，线程 #2 从 50MB 开始。 当线程完成时，您将拥有单个组合文件（否则，使用单独的文件，您需要将线程 #2 的结果附加到线程 #1）。
ASCII 艺术尝试
话虽如此，我从来没有这样做过。 它甚至可能不起作用！ 可以想象，您可以使用其他一些同步机制在线程之间共享文件句柄/流，但随后您还必须重置每个线程上的偏移量。 也许其中之一更有效。
一方面，如果两个线程总是同时写入，则可能会出现大量磁盘抖动。 相反，如果写锁存在大量争用，则同步写入可能会抵消并发的好处。 正如人们常说的，分析和测试！
无论如何，我也对使用共享写入访问的“现实生活”场景感到好奇，并将关注更多答案！
I'll hazard a guess... one thing it may be used for is for parallel computations. Say you have two threads doing some highly parallelizable computation and you need the data to be written to a single file. You're also able to pre-determine the size needed to store the output of each thread (say 50MB).
So, allocate a 100MB file, have thread one start writing at offset 0 and thread #2 start at 50MB. When the threads complete you will have your single, composed file (otherwise, using separate files, you'd need to append the result from thread #2 to thread #1).
ASCII Art Attempt
All that said, I've never done this. It may not even work! You can conceivably just share the File Handle/Stream between threads using some other synchronization mechanism, but then you'd have to also reset the offset on each thread. Perhaps one or the other is more efficient.
On one hand there could be lots of disk thrashing if both threads are always writing simeltanouesly. Conversely, syncing the writes may negate the benefits of concurrency if there is a lot of contention on the write lock. And as often said, profile and test!
Anyways, I'm also curious about a "real life" scenario where shared write access has been used and will be watching for more answers!
低于文件 I/O 级别的套接字。
假设服务器侦听某个本地端口 1999 并将入站中继转发到服务端口 3128 上的所有订阅客户端。
服务器可以从多个本地客户端读取数据并中继到多个远程客户端。 如果服务器是身份验证守护程序，则多个本地应用程序可能会尝试通过同一服务器（服务）进行身份验证。 可以通知远程客户端用户 x 现在已通过身份验证，因为他/她已成功登录到共享身份验证服务器的应用程序之一。
我不知道我在说什么。 我大胆猜测一下。
Sockets on a level lower than File I/O.
Say a server listens on some local port 1999 and relays inbound to all subscribing clients on service port 3128.
The server could read from multiple local clients and relay to multiple remote clients. If the server were an authentication daemon, multiple local applications might attempt to authenticate via the same server (service). The remote clients could be notified that user-x is now authenticated because s/he logged in successfully to one of the apps sharing authentication server.
I don't know what I'm talking about. I'm venturing a guess.