In comp.lang.java.advocacy, Roedy Green
<see_website@[EMAIL PROTECTED]
>
wrote
on Tue, 24 Jun 2008 09:53:25 GMT
<8fg1649pur9gbvnrsrcc8k4spv4amvomaf@[EMAIL PROTECTED]
>:
> On Mon, 23 Jun 2008 01:54:08 GMT, Roedy Green
> <see_website@[EMAIL PROTECTED]
> wrote, quoted or indirectly quoted
> someone who said :
>
>>Today, when we have RAM coming out our ears we have reverted back to
>>SINGLE buffering. We alternate between processing and waiting for I/O
>>on the same buffer.
>
> I will offer this hypothesis. Double buffering requires multitasking.
> This is perceived as complicated,
It *is* complicated. Multitasking among other things
requires lock synchronization, so that two tasks sharing
a resource don't clobber it.
One of the more interesting disciplines that got left
behind was the notion of coroutines as well. (That's
probably a side issue in this particular thread.)
> and hence was left out of early
> personal OSes such as CPM where you might have had only 4 to 64K to
> play with.
>
> In the 1940s to circa1970 , computers primarily did batch processing
> and worked on one problem at a time. Hence the elapsed time for batch
> processing was very im****tant. Double buffering helps this.
And was relatively simple to set up, if one had access to
the interrupt vectors directly.
>
> Later with mainframes, you had several batch jobs running at once.
> Here the computer could work on some other job while a batch job was
> blocked on i/o. Double buffering became less im****tant.
>
> Today with desktops there is little sequential batch processing.
> Double buffering is for sequential batch processing. Unlike COBOL, C
> and Java don't have the notion built in. Even if the OS offered it, it
> would take a while for it to become sup****ted again.
>
> In my world, I tend to read/write entire files in one i/o operation..
> Double buffering could not beat that.
I can do one better, though I rarely bother (I've seen
it done by a co-worker though); one can set up a virtual
memory area that is associated with a file, and then access
the area using char* pointers. The file load in this case
is done on an incremental basis, with pages faulting in as
needed. (mmap()/mmap2(), mremap(), munmap().)
Java does sup****t this concept as of 1.5 or so; I've not
tried it though.
>
> The reason may be that sequential batch processing is now considered a
> niche application.
>
--
#191, ewill3@[EMAIL PROTECTED]
Because it's there and it works.
Windows. It's there, but does it work?
** Posted from http://www.teranews.com
**
|
