The Question is:
Threads Vs Asynchronous I/O, performance throughput
In Butenhofs book, Programming with POSIX Threads ... the author (who
i believe was heavily responsible for Pthreads on OpenVMS + TRU64),
>> Asynchronous I/O does have one advantage over threaded concurrency,
>> though. Just as a thread is "usually" cheaper (in execution time and
>> storage space) than a process, the context required for an Asynchronous
>> I/O is almost always cheaper than a thread. If you plan to have a lot
>> of Asynchronous I/O operations active at the same time, that might be
>> important enough to justify using the more complex programming model.
Q1) - By enlarge, do/does the wizard(s) agree with the above statement
in respect of VMS ?
Q2) - Has anyone at ComPaq performed testing comparing the
Threaded Vs Asynchronous I/O models.
Based upon Butenhofs statement, it seems the best approach is to
combine both Asynchronous I/O + Threads. Agreed, this is more
complex, you are limited in what you can do within the AST (limited
of Pthreads from an AST) but thats fine, get in, enqueue ptr to
data to main, issue new i/o, and get out. The main line code can then
decide where to route the request for processing, a thread, or
Indeed for what i have in mind, an i/o intensive server (1000+
connections) where the received request usually results in a cpu
instensive operation, being handled internally by a thread (one per
cpu), or the request being handed off to another external process,
this methodology (although somewhat complex) seems a fairly
intuitive way of keeping the cpu's busy doing useful work.
Since a collegue disagrees with this methodology on the grounds
of performance / throughput, and we do not have the luxury of
writing multiple servers to compare the performance differences ...
Q3) - How you any comment in respect of the above model, is it fately
flawed, have i missed something ?
The Answer is :
As for the quote -- as written, yes, that is entirely correct.
Now as for whether or not that correctness really matters here...
The OpenVMS Wizard does not believe you can or will receive an answer
more specific than "it depends" -- it depends on the particular target
system, growth, and headroom, on the amount of effort you are willing
to expend for programming and debugging, on the number of systems you
plan on using, on requirements for clustering, and on various other
factors. Threads, ASTs, and local or distributed processes are all
potential approaches to solving this -- each has various advantages
and disadvantages, rather obviously.
Also please see topic (6099) for some details of threads-related