3

consider the following scenario:

  1. Process 1 (Writer) continuously appends a line to a file ( sharedFile.txt )
  2. Process 2 (Reader) continuously reads a line from sharedFile.txt

my questions are:

In java is it possible that :

  1. Reader process somehow crashes Writer process (i.e. breaks the process of Writer)?
  2. Reader some how knows when to stop reading the file purely based on the file stats (Reader doesn't know if others are writing to the file)?

to demonsterate

Process one (Writer):

...
while(!done){
 String nextLine;//process the line
 writeLine(nextLine);
 ...
}
...

Process Two (Reader):

...
while(hasNextLine()){
  String nextLine= readLine();
  ...
}
...

NOTE:

Writer Process has priority. so nothing must interfere with it.

nafas
  • 5,283
  • 3
  • 29
  • 57
  • 2
    I have the feeling that you want a shared BlockingQueue. Not a shared file. http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/BlockingQueue.html – JB Nizet Jun 30 '15 at 11:13

4 Answers4

3

Since you are talking about processes, not threads, the answer depends on how the underlying OS manages open file handles:

  1. On every OS I'm familiar with, Reader will never crash a writer process, as Reader's file handle only allows reading. On Linux, system calls a Reader can potentially invoke on the underlying OS are open(2) with O_RDONLY flag, lseek(2) and read(2) -- are known not to interfere with the syscalls that the Writer is invoking, such as write(2).
  2. Reader most likely won't know when to stop reading on most OS. More precisely, on some read attempt it will receive zero as the number of read bytes and will treat this as an EOF (end of file). At this very moment, there can be Writer preparing to append some data to a file, but Reader have no way of knowing it.

If you need a way for two processes to communicate via file, you can do it using some extra files that pass meta-information between Readers and Writers, such as whether there are Writer currently running. Introducing some structure into a file can be useful too (for example, every Writer appends a byte to a file indicating that the write process is happening).

For very fast non-blocking I/O you may want consider memory mapped files via Java's MappedByteBuffer.

Sergey Mikhanov
  • 8,880
  • 9
  • 44
  • 54
0

The code will not crash. However, the reader will terminate when the end is reached, even if the writer may still be writing. You will have to synchronize somehow!

loonytune
  • 1,775
  • 11
  • 22
  • won't flushing frequently add to the end of the file? Like in Linux where you can both read/write at the same time. – Mackiavelli Jun 30 '15 at 11:11
  • indeed, as i said, you can write and read at the same time. still, if the reader catches up to the writer, and tries to read, it WILL NOT wait for more data, it will return EOF and indicate to the java stream that the end of the file has been reached and no more data can be read. If you would open another stream later, it will be able to read more data, until you catch up to the writer and the same problem arises again. – loonytune Jun 30 '15 at 19:01
0

Concern:

Your reader thread can read a stale value even when you think another writer thread has updated the variable value

Even if you write to a file if synchronization is not there you will see a different value while reading

Ankur Anand
  • 3,873
  • 2
  • 23
  • 44
0

Java File IO and plain files were not designed for simultaneous writes and reads. Either your reader will overtake your writer, or your reader will never finish.

JB Nizet provided the answer in his comment. You use a BlockingQueue to hold the writer data while you're reading it. Either the queue will empty, or the reader will never finish. You have the means through the BlockingQueue methods to detect either situation.

Community
  • 1
  • 1
Gilbert Le Blanc
  • 50,182
  • 6
  • 67
  • 111