From: Alan Gutierrez on 30 Jul 2010 14:00 Daniel Pitts wrote: > On 7/30/2010 9:21 AM, Knute Johnson wrote: >> On 7/29/2010 9:35 PM, Boris Punk wrote: >> That is a common usage for RWL. The reading threads can be blocked when >> a write is about to occur. The actual read/write to the disk is another >> matter altogether. Caching and other things can affect that as well. > Perhaps its a common usage for the general concept of read/write lock, > but in Java, the ReadWriteLock wouldn't be useful, since it doesn't > prevent external processes from accessing the file. > > One place that the Java ReadWriteLock is useful for a Many-Access, > Few-Write data-structure (eg, configuration object which changes rarely, > but is used in many places). It is still useful for guarding a file within the process, though, if the underlying file will only be read and written to by your one Java process. -- Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: Daniel Pitts on 30 Jul 2010 14:17 On 7/30/2010 11:00 AM, Alan Gutierrez wrote: > Daniel Pitts wrote: >> On 7/30/2010 9:21 AM, Knute Johnson wrote: >>> On 7/29/2010 9:35 PM, Boris Punk wrote: > >>> That is a common usage for RWL. The reading threads can be blocked when >>> a write is about to occur. The actual read/write to the disk is another >>> matter altogether. Caching and other things can affect that as well. >> Perhaps its a common usage for the general concept of read/write lock, >> but in Java, the ReadWriteLock wouldn't be useful, since it doesn't >> prevent external processes from accessing the file. >> >> One place that the Java ReadWriteLock is useful for a Many-Access, >> Few-Write data-structure (eg, configuration object which changes >> rarely, but is used in many places). > > It is still useful for guarding a file within the process, though, if > the underlying file will only be read and written to by your one Java > process. > That is true, but I wouldn't say it is a "common" usage for ReadWriteLock. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Lothar Kimmeringer on 1 Aug 2010 04:27 Boris Punk wrote: > How can that be? Imagine Thread A calling seek on the disk, then Thread B > calling seek. This scenario are quite common in multitasking operating systems. If you open a file on OS-level you get a so called file handle (a number more or less). Every subsequent operation (like a seek) need this handle. That way you can distinguish between the two reads even if they happen to be on the same file. > Thread A then reads from B's location surely? No. You don't expect that to happen if you receive data via TCP/IP from the same host via two different TCP- connections. They also go through the cable in a serial way. Regards, Lothar -- Lothar Kimmeringer E-Mail: spamfang(a)kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions!
From: Olaf Klischat on 4 Aug 2010 18:52
On 07/30/2010 04:58 AM, Boris Punk wrote: > I'm not sure about this one. The basic IDE hard drive hasn't got the > capability to read from two disk locations at the same time has it? Modern > SSD drives may have. > > This lock is stating that multiple reads are ok, but just one write at a > time is ok: > http://download.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReadWriteLock.html > > How can that be? Imagine Thread A calling seek on the disk, then Thread B > calling seek. Thread A then reads from B's location surely? As somebody else said, RWL is not directly related to file IO. For accessing the same file from multiple threads, each thread would normally create its own FileInputStream or FileOutputStream for that file. The seek position is a property of such a stream, not of the file itself, so each thread ends up having its own seek position and the threads won't interfere (in fact, this will also allow you to have multiple seek positions on the same file in just one thread -- just create multiple streams as necessary). |