|
HP OpenVMS Systemsask the wizard |
|
The Question is: Dear Wizard, I have a contractor in here writting code which does multiple disk I/Os (using qiow() from inside ASTs. In particular these ASTs are generated from qio "socket" reads. I was, and still am unless you tell me otherwise, under the impression that one shou ld limit the amount of code executed inside an AST. I am having trouble convincing him that this is probably not a good implementation technique. What are your feelings? Thanks, John E. Frank frankjo@us.polygram.com The Answer is : The Wizard commends you for your attitude regarding AST code -- keeping it to the minimum will greatly improve your odds of success (you obviously had a proper VMS upbringing). On the other hand, it is valid to perform "well-defined" operations from within AST code, and your contractor's approach is covered under this. His proposal is commonly refered to a "chaining I/Os", whereunder each I/O's completion requests the next I/O, which results in the process always having an I/O outstanding on the channel. [The Wizard is boldly presuming here that your contractor is using $QIO and -not- $QIOW as your post suggested.] The tricky part of this is managing the buffers and IOSBs, and keeping the mainline code running sufficiently to consume all of the I/Os (or providing some mechanism for throttling it). Back on the first hand, however, VMS now provides another alternative mechanism for multiprogramming: threads. Your application can create a thread for each I/O channel, and the threads perform the I/Os using straightforward synchronous calls (potentally allowing you to use RMS calls or high level language run-time calls instead of tangling with $QIO). This approach requires no ASTs or interrupt-style programming, and the code in general is much simpler to read and understand. However, it does require switching to the multithreaded programming paradigm, with the attendant learning curve. Nevertheless, there are additional benefits to using threads, such as the ability for full parallel execution on SMP machines. (See "The Guide to DECthreads" in the programming section of the VMS doc set.) In conclusion, it sounds like your contractor is a good VMS programmer from the old school, and if that's true his approach should yield a good, high performance result when used in a non-threaded application. However, there now exists better technology which, depending on your requirements, could yield superior performance with simpler code, and you/he should consider using threads.
|