|
HP OpenVMS Systemsask the wizard |
|
The Question is: I thought i had read somewhere, within a VMS manual, maybe even in the IDSM ?, that you should NOT have more than one $QIO operation pending on a device at a time. I then found this Q+A paragraph at the TGV site, >> In the "$QIO Interface" sectioni of The MultiNet Programmer's >> Guide, a note is listed as saying: >> If more than one $QIO operation is pending on a socket at any >> one time, there is no guarantee that the $QIO calls will complete >> in the order the are queued ... the data may be interleaved." >> As a curiousity, what is the reason behind this?? The supplied answer was:- >> The reason behind this has to do with the design of the BSD >> TCP/IP kernel on which MultiNet is based on (the kernel is >> the actual BSD 4.3 code). In that design what happens on a >> write is if there is no room in the socket snd buffer then >> it creates what is known as a "miniprocess" which waits until >> there is room. However once a write has been "deferred" as >> a miniproc then there is nothing to prevent the next write >> from actually making it into the socket buffer. Thus an >> asynch write of "ABC" followed by a asynch write of "DEF" >> could be seen as a "DEF" followed by "ABC" on the receiving end. >> Please note this can only happen on $QIO's not $QIOW's since a >> $QIOW will cause you to block until the IRP is posted. I normally chain my qio's together. i.e. I maintain a pending queue per channel (be it DecNet or TCP or UDP). When the AST completes successfully, the buffer just sent is returned to the free-pool, I de-queue next buffer from the pending-queue, and issue a asynchronous qio write. Q) A curiosity ... In respect of a mailbox, LAT, UCX + DECNET, is it permissable to issue multiple ASYNCHRONOUS qio writes?, or would the possibility of interleaving exist ? If this can happen, could you explain why If NOT, is there any likely performance gain by issuing multiple qio writes ? thanks The Answer is : Under OpenVMS, multiple I/O operations can be outstanding on the same device at the same time. The specific behaviour of the device driver and of the application is directly involved here, with factors ranging from the driver's ability to process multiple I/O operations to the particular (re)ordering of the I/O completions that might occur. Most drivers operate without explicitly reordering operations, but it is certainly possible that reordering can occur -- one example of a case where reordering might be of interest involves the performance improvements from reordering the disk I/Os operations into seek order.
|