Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #3618

Re: DPANS94 BLOCK/BUFFER ambiguity?

Show all headers | View raw

On 6/28/11 11:19 AM, Jean-François Michaud wrote:
> I was wondering what you guys' thoughts were regarding the BLOCK/
> BUFFER definition in the standard which seems, to me, to be ambiguous
> at best.
>
> There seems to be an implicit assumption here that ANS94 doesn't
> address very well. Because BUFFER exists, we can't really assume that
> the address returned by BLOCK contains mass-storage content unless we
> enforce it. We are trading speed (buffering) for accuracy (assurance
> that disk block content is present in the buffer). The standard seems
> to want to address both accuracy and speed simultaneously but
> seemingly creates an logical ambiguity instead.

You are correct, there are some implicit assumptions here.  The main one 
is that BUFFER is almost never used in application code.  An exception 
is in a disk copy or initialization utility, in which since you are 
going to overwrite the content of the block anyway there is no need to 
do a READ. Basically, you should think of BUFFER as an underlying factor 
of BLOCK which is exposed for use in a very narrow range of 
circumstances, in which the programmer must understand the consequences. 
  Never use BUFFER unless you are absolutely sure you do not care what 
the contents of that block are because you are about to replace them.

> Trivially, "5 BUFFER 5 BLOCK" would yield the buffer address upon
> calling block but without the particular assigned buffer containing
> mass-storage content.

One wouldn't want to do that.  This is why the text has all the warnings 
about exactly what these words do.

> For content accuracy, per my understanding, block MUST read from disk
> *everytime*. For speed, accuracy can be sacrificed by returning a
> buffer address without knowing whether the buffer contains mass-
> storage content or not, effectively giving precedence to BUFFER over
> BLOCK (alternatively, accuracy would give precedence to BLOCK over
> BUFFER except when a BUFFER is UPDATEd).

To avoid confusion, user code should avoid BUFFER.  By sticking to BLOCK 
you will get both excellent reliability and excellent performance.

> Interestingly, and quoted from DPANS94, and taken from both the BLOCK/
> BUFFER definition, "If block u is already in a block buffer, a-addr is
> the address of that block buffer." cannot be strictly determined
> without doing a comparion between the content of the buffer and the
> mass-storage content for the associated block number which implies a
> systematic mass-storage read or a mirror image of mass-storage being
> present and maintained in memory for such a comparison to take place.
> So we can generally extrapolate that the standard doesn't intend for a
> very heavy implementation and is thus implicitly giving precedence to
> BUFFER over BLOCK while assuming speed over accuracy.

In fact, it is inappropriate to assume that a block in a buffer should 
be identical to its disk equivalent, since it may have been modified 
since it's been in memory, and the buffer marked UPDATEd.

In my experience, accuracy isn't impaired at all.  Native (i.e., no host 
OS) block systems have been used in very large and complex data base 
applications, with many users and intense requirements for data 
security, and OS-hosted versions have shown equivalent reliability, 
though with much slower performance.

Even though disks are a lot faster nowadays, a disk read consumes many 
microseconds compared with memory-only operations, and in a 
disk-intensive application the number of physical disk accesses becomes 
a dominant factor in performance. Professional implementations even try 
to avoid unnecessary disk accesses by doing things like picking the 
least recently accessed buffer to overwrite when a READ is to be done, 
and such efforts can show significant performance improvement.  On 
hosted systems the necessity for an OS call to get a block makes the 
overhead even worse.

Nowadays, we find blocks being implemented in flash, which changes some 
of the tradeoffs, but the principles are the same.

> Also, DPANS94 ends the definition with: "At the conclusion of the
> operation, the block buffer pointed to by a-addr is the current block
> buffer and is assigned to u". Somewhat assuming that mass storage is
> accurately reflected when this is strictly incorrect given the above.

It will be correct if the programmer avoids introducing ambiguity by 
using BUFFER inappropriately.

> Also, doesn't the standard imply implementation details? A simple
> modular arithmetic implementation for buffer assignment while assuming
> accuracy over speed, for example, would simply yield a buffer that
> would either reference the disk block content or not and would have
> the desired block number assigned to it or not.
>
> Similarly, In the modular arithmetic implementation argument provided
> above, and still assuming accuracy rather than speed, determining
> whether block<n>  is present or not and associated to a buffer may be
> irrelevant if a mass storage MUST be read when calling BLOCK; BUFFER
> only gaining precedence over BLOCK in the case where a BUFFER is
> UPDATEd.
>
> Thoughts?

Not sure what you mean by a modular arithmetic implementation.  Of 
course some implementations will be more successful than others, but I 
think there's enough info for compliance.  ANS Forth tries to focus on 
semantics, not implementation.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

DPANS94 BLOCK/BUFFER ambiguity? Jean-François Michaud <cometaj@comcast.net> - 2011-06-28 14:19 -0700
  Re: DPANS94 BLOCK/BUFFER ambiguity? Elizabeth D Rather <erather@forth.com> - 2011-06-28 14:06 -1000
  Re: DPANS94 BLOCK/BUFFER ambiguity? Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 12:46 +0100
    Re: DPANS94 BLOCK/BUFFER ambiguity? Jean-François Michaud <cometaj@comcast.net> - 2011-07-03 09:38 -0700
      Re: DPANS94 BLOCK/BUFFER ambiguity? Elizabeth D Rather <erather@forth.com> - 2011-07-03 08:44 -1000

csiph-web