From: winalski@adserv.enet.dec.com (Paul S. Winalski)
Subject: Re: $QIO: What happens within?
Reply-To: winalski@adserv.enet.dec.com (Paul S. Winalski)
Organization: Digital Equipment Corporation, Nashua NH
Distribution: na
Date: Tue, 15 Dec 1992 03:39:44 GMT


In article <1992Dec14.164552.28939@bnlux1.bnl.gov>,
kushmer@bnlux1.bnl.gov (christopher kushmerick) writes:
|>
|>What is the sequence of events when a qio is executed? In particular:
|>
|>
|>I am using a $QIO to send data between mail boxes. I have a global structure
|>which is updated at AST level by various tasks. When I get a request from 
|>another program, I send the structure by qio, specifying the address of the
|>actual global structure, rather than first making a copy.
|>
|>This is in FORTRAN so both the global structure and any local copies would be
|>at some fixed location in memory and _NOT_ on the stack.
|>
|>
|>Here is the question: Does $qio (not $qiow) make its own copy of the data 
|>prior to returning, or does it just use the data at the memory location speced?

The exact behavior of $QIO in this regard is totally up to the driver for the
device to which you are issuing the request.  All that is guaranteed is that
if $QIO returns with success status, it means your I/O request has successfully
been queued to be processed on the device.  It doesn't mean that the I/O
transfer has actually started.  It is an error to write code with such
dependencies.

|>Here is what I am worried about
|>
|>1) Stack frames: If I were doing this in Pascal or C and sent a local
|>variable via qio. By the time the qio got around to actually sending the data,
|>the routine that called the qio may have returned, the stack frame would no
|>longed be valid and who knows what might be in the (stack) memory location that
|>used to contain the data.

Yes, this is a valid concern.

|>2) The data in my case is updated by ast-level interrupt routines. What if
|>the updating routine is executing when the $qio is ready to start shipping the 
|>data. Will the qio interrupt the ast routine to ship the data?

The $QIO system service has done its work when it returns to you.  However,
the device driver, which is the piece of the VMS I/O system responsible for
processing the I/O requests enqueued by $QIO, may indeed interrupt your
program at any time.  Unless you're doing something kinky, the program in your
process is executing at IPL (interrupt priority level) 0.  Device drivers
typically run at IPL 8 or above (the mailbox driver runs at IPL 11), and so
they will preempt any user process code when they have work to do.

|> Does it
|>matter if the qio was called at AST level or at "normal" level?

No.  User-mode AST level does not matter to device drivers.

|> Is it possible
|>that the data will be corrupt due to incomplete updating of the data?

If you are updating a buffer while there is a $QIO outstanding on it, yes,
the data might be corrupted.

|>Perhaps a milbox is a bad example because it is all memory. what if I was 
|>sending large amounts of data down a slow serial line, using local 
|>variables in a stack-frame language like pascal.

The rule is, once you star an I/O operation, you must keep your hands off the
buffer until the I/O system indicates that the operation has completed, either
by posting the event flag and IOSB, or by delivering an I/O completion AST.
Results are unpredictible if you write into the buffer while a write I/O is
in progress, or if you read from the buffer while a read I/O is in progress.

For languages such as C, Pascal, or PL/I, you should not use automatic storage
class variables as I/O buffers, if you want to return from the routine in
which the variable is defined before the I/O is completed.  You should either
declare the variable static (or own), or use heap-allocated memory instead of
stack memory.

Note that all of the above is true for the mailbox driver as well as for
"real" device drivers.  The internal operation of the mailbox driver is subject
to change, and any atomicity of its behavior with respect to modification
of the I/O buffer while an I/O is in progress could change in a future version
of VMS.

Bottom line:  keep your hands off the I/O buffer while an I/O is in progress.

--PSW