Is not the simplest solution to allow each thread to get a reference to the *single* RandomAccessFile instance and simply synchronize on it while reading (not forgetting to reset the offset into the file). It's not going to be super performant, but how is it ever going to be with multiple threads thrashing on one file? If anything it might reduce thrashing as you are controlling the points of file contention. What is the ratio of time spent reading the file to time spent operating on the data?
If all these threads will in-fact thrash on the file it might only be solved with: 1. Better scheduling than "free for all" threads. 2. a large OS level disk cache 3. an in memory disk cache 4. some kind of abstract layer over the file which does caching and returns you "model objects" rather than being seen as a byte stream. On Dec 25, 1:38 am, Eitan <eitan...@gmail.com> wrote: > Looking at FileChannel it has the following part in its documentation: > > The view of a file provided by an instance of this class is guaranteed > to be consistent with other views of the same file provided by other > instances in the same program. The view provided by an instance of > this > class may or may not, however, be consistent with the views seen by > other > concurrently-running programs due to caching performed by the > underlying > operating system and delays induced by network-filesystem protocols. > This > is true regardless of the language in which these other programs are > written, and whether they are running on the same machine or on some > other > machine. The exact nature of any such inconsistencies are system- > dependent > and are therefore unspecified. > > This looks exactly like the guarantee I need, now I've looked into > RandomAccessFile.getChannel() implementation and it holds a single > member of FileChannel which is initialized on demand and the next > calls will return the same instance. > > So the only way I see to create multiple FileChannel instances over > the same file is to open multiple RandomAccessFile instances over that > file and use getChannel() on each of these instances. Since > FileChannel does provide this guarantee I tend to believe it relies > upon a guarantee that RandomAccessFile provide, otherwise it would > need some mechanism to identify that different FileChannel instances > over different RandomAccessFile instances are actually over the same > file in order to provide the specified guarantee. > > What do you think? > > On Dec 21, 9:33 am, Ben Schulz <ya...@gmx.net> wrote: > > > > > My guess is that Java IO takes advantage of any OS optimizations there > > are, on another OS there may be a per-file-pointer cache or something. > > That would obviously invalidate your assumptions. I suggest you look > > into using asynchronous I/O which will get rid of any multiple-reader- > > bottlenecks. This should also rule out third parties tampering with > > the file (since you already hold the write lock). > > > With kind regards > > Ben > > > On 21 Dez., 07:50, Eitan <eitan...@gmail.com> wrote: > > > > I am trying to avoid locking the access to file for multiple readers > > > can be multi concurrent readers and it will be a bottleneck. > > > I've created a multi threaded test for it and it seems to work fine, > > > but I am not still not confident about it. I was hoping to find some > > > documentation about it which specifies the behavior. > > > > On Dec 20, 11:40 pm, Christian Catchpole <christ...@catchpole.net> > > > wrote: > > > > > Can you even get a second lock on a file that way? Sounds dangerous. > > > > I would just create a some kind of service that each Thread can access > > > > that will synchronise disk access down to one RandomAccessFile. > > > > > On Dec 21, 2:48 am, Eitan <eitan...@gmail.com> wrote: > > > > > > I want to use a file in a single process with single writer or multi > > > > > readers mutual exclusion, for that purpose I use number of > > > > > RandomAccessFile instances over the same file which are open in read > > > > > mode and are used concurrently. I also have a single RandomAccessFile > > > > > open in "rw" mode which updates the file (not when it is being > > > > > actively read). > > > > > I do not close the Random Access File handles at any point. > > > > > > I wanted to know if the data which is being written to the file with > > > > > the RandomAccessFile in rw mode will always be visible to the readers > > > > > after the the write is complete? > > > > > (I am not using rws mode for performance issues, only for these > > > > > readers which are in the same process). > > > > > > Thanks > > > > > Eitan -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
