4

I have a problem with reading and writing to a file in a 'shared mode'. What my application needs is to be able to access file -or open- in a shared mode so that if one thread is writing to a file another should be able read from it. I have seen java.nio.channels.FileLock, however it has a problem, which I am quoting

So what else could be the solution to access in 'shared mode' to a file? To let multiple read accesses and to let read while writing or vice versa. It would be great if I could specify the mode while I open the file for example..

hope everything is clear..

P.S. I' m using jdk 1.6 so java.nio.Files is not supported.

Guillotine1789
  • 342
  • 4
  • 12
  • This just means that you have to make sure in application code that your threads don't step on each-others' feet. – Thilo Jan 23 '15 at 09:34
  • 1
    Why do you need "shared mode"? If it is only one process accessing the file at the same time, exclusive mode seems much safer. Otherwise you have to not only coordinate your own threads (which is relatively easy using JVM thread synchronization), but also across processes/JVM. – Thilo Jan 23 '15 at 09:36

3 Answers3

0

If you are synchronizing threads you can use the Java concurrent classes. There is an implementation of read-write locks:

ReentrantReadWriteLock JavaDoc 7

ReentrantReadWriteLock JavaDoc 5

The documentation gives an example of usage. Of course, you will need the FileLock as well to synchronize across processes.

The second example is probably most useful for you, but instead of accessing a collection you will be accessing your file. Your FileLock operations will go inside the ReentrantReadWriteLock locked code.

rghome
  • 8,529
  • 8
  • 43
  • 62
0

The FileLock is to coordinate file access with other processes.

You do not need it (nor does it help) to coordinate file access between the threads of your own process.

If I understand you correctly, you should get an exclusive lock on the file to prevent other programs from messing with it while your Java program works on it, and then make sure somehow in your application code that the various threads you have don't step on each-others' feet.

The latter can be done with Java thread synchronization.

Thilo
  • 257,207
  • 101
  • 511
  • 656
  • We want to allow multiple threads to read the file concurrently to improve performance, and only block if we are writing. There is no point in having multiple file access threads if only one can access the file at a time. – rghome Jan 23 '15 at 10:19
  • All your threads can access the file at the same time. It is entirely up to your application to synchronize them appropriately (nothing else does). – Thilo Jan 24 '15 at 00:55
0

First idea:

What about this solution... Every thread has it's own java.io.RandomAccessFile instance in "rws" (or "rwd") mode for updating operations and "r" mode for just reading operations.

Since there is no buffering (caching) in java.io.RandomAccessFile and because of the "rws" (or "rwd") mode of the updaters, they all "see" the changes from each other.

Of course, you would still have to control in your application/library/framework that the threads do not overwrite unintentionally each others changes (think of atomic/compareAndSwap updates) and mess things up.

Second idea:

For better performance and when your application (a single process instance) is the only accessor of the file, you could abstract the file with a little layer which cares about buffering and synchronization. Problably there is already an implementation somewhere...

Peti
  • 1,670
  • 1
  • 20
  • 25