From: Alan Gutierrez on
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
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
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
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).