Regardless of whether a thread issues a synchronous call, or
an asynchronous call, both are obviously actually handled by
the OS itself. When the I/O completes it will let us know.
Quote:>>>> Why cheating ?
What i dislike about the Threads implementation is if you
have a busy server, say several thousand connections you
also have several thousand threads. This is a LOT of
contention / context switching. After all, if you only
have two cpu's, you can NOT have more two threads active
at any time.
Thus for those OS's that support async I/O directly within the
Kernel (OpenVMS, TRU64, WNT), you can queue multiple async
requests, and keep just a couple of threads really busy, and
thus avoid context swicthing.
Also, everything I have read, suggest that the Async I/O model,
though more complicated, is usually superior in respect of
> > You are going to have problems implementing the 2nd option on some
> > Some Unixes do not have threads. Sco Openserver comes to mind. They
> > some thing like threads but its not build into the os.
> > > Hi,
> > > I originally posted a very similar question to that posted below
> > > comp.programming.threads, but received no replies
> > > So here's hoping
> > > In respect of HP-UX, Solaris, TRU64, AIX and IRIX and various
> > > how have the different OS's implemented Async I/O ... ie POSIX.4
> > > 1) Modify the OS so that the OS supports the Async I/O
> > > 2) Cheat, and support it via threads, thus 100 async i/o requests
> > > have 100 threads doing the I/O for you
> > > 3) ??
> > > Thanks inadvance
> > > -Fred
> HPUX and Solaris now support async I/O primarily thru method  above.
> last version of Irix (4.2?) which I saw did have specific aio_xxx
> (which actually resulted, the first time they were called in the creation
> multiple 'sprocs' which did the actual I/O for you). I'm not sure why you
> to multi-threading as "cheating" though, since the aioxxx/aio_xxx
> other systems actually result (typically) in the kernels of those OS's
> the threads in kernel mode to do the I/O operations. The use of
> to do async I/O is actually an optimization of the earlier methods which
> in a "cleaner" form of coding...you (the programmer) have to pay attention
> the synchronization of threads and application shared data, which is often
> referenced when doing I/O operations...this is a relatively small price to
> for programs which are simpler to understand, and easier to maintain.
> Software Engineering,
> Open Image Core Product Group