Is there any reason to open a file with shared-write access?

Question

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?

Answer 1

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

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

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!

Answer 2

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.

Answer 3

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()