"Knute Johnson"<nospam@rabbitbrush.frazmtn.com> wrote in message
news:o_C4o.33262$OU6.16033@newsfe20.iad...
On 7/29/2010 9:35 PM, Boris Punk wrote:
"Arne Vajh?j"<arne@vajhoej.dk> wrote in message
news:4c52403f$0$283$14726298@news.sunsite.dk...
On 29-07-2010 22:58, 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 ThreadB
calling seek. Thread A then reads from B's location surely?
The ReadWriteLock is not related to the actual disk IO - it only
coordinates between two or more threads.
Fair enough - I was just read somewhere someone tried using it for a disk
IO
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.
a typical OS, such as Windows or Linux, will almost entirely abstract the
matter of (actual) disk IO from the app. so, when apps do IO, they are
usually doing it against structures within the OS, rather than anything near
the actual disk.
similarly, IO libraries (C's "stdio" system being an example) may in-turn
cache data, to reduce the overhead of system calls (doing a system call for
every little read or write operation could become expensive).
so, for example:
Java app does IO;
request goes to the JVM, which may in turn pass IO requests to C-level
libraries on the OS on which it is running (glibc or MSVCRT, or maybe Win32
API calls?...), which may do their own buffering;
these in turn perform system calls, to pass these requests to the kernel;
the kernel may in turn do some of its own buffering (a request may be read
from a buffer, written to a dirty buffer, or queued to be serviced later);
at its leisure, the kernel may send its requests to a device-driver, which
may in turn redirect said requests to the actual HW;
in turn, the drive may itself do some of its own buffering (similar to the
OS kernel), writing disk-blocks when it has a chance, or reading disk blocks
and notifying the OS that it has done so.
note that threads at one level, need not necessarily exist at another level;
the threads in Java code need not actually exist in the VM (a VM could
conceivably be single-threaded, and implement its own scheduler to simulate
multithreading in the running code);
the threads in the underlying app need not manifest in the actual OS (the
kernel could easily see only a single thread per core or similar, and from
its point of view, it simply passes control temporarily to the running app,
and when it gets control back, may in turn pass control to the next app, and
so on, and eventually get back around to the first app, ...);
the drive likely doesn't give a crap about threads, only that the commands
it recieves make sense.
them interacts with the ReadWriteLock class. That class is