Knute Johnson said:
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.
in many systems, the OS has typically only provided a single process
(naturally single-threaded), and the existence of threading has in such
systems often been provided via library code (typically relying on some
signal from the OS, such as a timer, to facilitate context switching). also
common is the app having to perform some action (such as sleeping or
checking an event queue), which gives the OS or thread-library a chance to
switch threads (this having been done on Win 3.x, and in some MS-DOS
threading libraries).
note that threading doesn't require any specific HW support, and so could be
done on an 8088 or similar if so desired (although care is needed, as the
ROM BIOS and MS-DOS are not generally thread-safe...).
real HW-level multithreading didn't generally take place until the rise of
multi-core systems and similar, and before this, it was nearly all done in
software.
granted, a typical OS such as Windows, is AFAIK multithreaded internally,
but these threads are unrelated to those existing in the app. (and,
actually, the kernel typically lives within its own, partially disjoint,
address space, which need not even necessarily be in the same operating mode
or using the same word-width as the currently running app, such as Windows
x64 running a 32-bit app, or Win32 running a 16-bit app).
or such...
