[Info-vax] Possible resolution of MB issue raised by 5.6.4.3 of 3d ed. AARM
Johnny Billquist
bqt at softjar.se
Tue Aug 25 18:34:42 EDT 2015
On 2015-08-25 07:15, George Cornelius wrote:
> In article <ueHtzhyzmj7c at eisner.encompasserve.org>, cornelius at eisner.decus.org (George Cornelius) writes:
>> See my comments regarding paragraph {3} for a likely resolution of
>> what I saw as a problem raised within this section.
>
> OK, and here is further confirmation via a comment in the IDSM
> (sorry - sketchy - from a google search using Lynx), in which it
> is declared that a kernel mode AST is queued to the process itself
> to perform the final phase of I/O processing. The driver code,
> essentially, via this O/S feature, performs all the synchronization
> at the 2nd processor that is required.
>
> Open VMS Alpha Internals and Data Structures: Scheduling and ...
>
> The $QIO service clears event flag 10, initiates the I/O request, and
> returns to ...
> The special kernel mode AST associated with the completion of that
> request is ...
> https://books.google.com/books?isbn=1555581560
Your quoting of the processor documentation is all valid and good. But
really covers this from a low hardware point of view. This is things
that partly is under the domain/control of VMS, and not individual
processes.
While I definitely do not know enough about the internals to say
anything for sure here, I would think that VMS would assure that when
the IOSB is written, the data buffer is also valid. That would mean that
VMS should issue a memory barrier once it writes the IOSB, and before
returning to user mode.
But maybe that is me hoping for too much from VMS. But I truly believe
that it is VMS responsibility to present a coherent view to the user
process, and hide these kind of processor oddities from user code.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
More information about the Info-vax
mailing list