File output and buffering

This is a discussion on File output and buffering within the ADA forums in Programming Languages category; On 23 Sie, 22:34, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote: > > Then we have a different notion of "synchronously". > > When I write something to the file, the operation is synchronous when > > the program *waits* for the transfer to complete. > > * * * * If I may slip in, since this thread has wandered into comparisons > that even I can't follow... > > * * * * Define "complete" So that the program can immediately terminate and still have the data reliably stored. Think about log files of various kinds (including database write ahead ...

Go Back   Application Development Forum > Programming Languages > ADA

Object Mix

Register FAQ Calendar Search Today's Posts Mark Forums Read
  #21  
Old 08-23-2008, 06:00 PM
Maciej Sobczak
Guest
 
Default Re: File output and buffering

On 23 Sie, 22:34, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:

> > Then we have a different notion of "synchronously".
> > When I write something to the file, the operation is synchronous when
> > the program *waits* for the transfer to complete.

>
> * * * * If I may slip in, since this thread has wandered into comparisons
> that even I can't follow...
>
> * * * * Define "complete"


So that the program can immediately terminate and still have the data
reliably stored.
Think about log files of various kinds (including database write ahead
logs) and the importance of having something confirmed.

> * * * * Most I/O systems I've encountered are buffered by the OS....


Of course - and not only that. There are buffers everywhere, even in
hard drives. The semantics of output operation from the program point
of view can be, however, described in terms of reasonably understood
best-effort or pushing data as far as it makes sense. For example, if
the hard drive can guarantee reliable storage at the level of its own
buffers, then it can confirm reception of the data without actually
storing them on plates. From the point of view of the program, the I/O
operation can be considered as finished, because from that point
nothing can mess things up.

> As far
> as an application is concerned, an I/O "write" operation is "complete"
> when the OS accepts the packet for buffering.


Exactly - provided that the packet was *copied* to OS buffers as
opposed to just passing pointer to programs data.

In practical terms:

Ada.Text_IO.Put_Line (File, "Hello");
Ada.Text_IO.Flush (File);
-- here we can crash without losing data

I consider the output operation above (triggered or ensured by Flush)
to be *synchronous with respect to the program*. When the Flush
operation returns the control back to the program, the data is already
stored in the external file (as AARM calls it), whatever that means,
even if the "external file" includes several layers of buffers. From
the program's perspective, it is "done".

If you want to contrast the above with asynchronous version, the
output operation can be initiated by the program but the program would
be allowed to continue without any guarantee related to the amount of
data being stored (and with some provisions to get the status later
on).

Short coverage of what all this means in the context of databases:

http://www.orafaq.com/node/93

It is really well written.

I hope that you get what I'm trying to say here. Well, at least I'm
sure that I'm not inventing anything new.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada
Reply With Quote
Reply


Thread Tools
Display Modes


All times are GMT -5. The time now is 05:33 AM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
vB Ad Management by =RedTyger=

In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.