In generic Asynchronus I/O (AIO) can be designed using User lavel or in Kernel level. **In user level** 1) Process needs async callback/notification create another thread and process which goes to sleep on blocking calls (read/write/ioctls/select) 2) One Async master handler (process/thread) keeps track.All the process needs the service submit job to them.The master handler handles the async fd in Blocking mode and reply to requesting processes (or call the callback function) using some async notificatin like signal. **In Kernel Level** 1) Call some system call and submit some job to kernel workQ .After work is complete kernel notify using signal to user space. **In VxWorks:** aioPxLib provide the POSIX 1003.1b standard.Which is task implementation of aio service. functions available: 1\) aio\_read() – initiate an asyn. read. 2\) aio\_write() – initiate an syn write 3\) aio\_listio() – Initiate a aio list upto LIO\_MAX 4\) aio\_error() – Get an aio error status. 5\) aio\_return() – Get aio return status. 6\) aio\_cancel() – Cancel a queued async operation 7\) aio\_suspend() – waits until an aio operation is done,complete or interrupted 8\) aio\_fsync()- Asynchronously forces file synchronization.

We create AIO control block (aiocb) structure:
member elements include file descriptors to I/O,buffer pointer,signal event.Application can know whether the submitted task is complete or not ,by signal event or by using aio_return which returns the status by polling.
VxWorks spawn aio task to service the requests.The no of spawned task is the no of maximum simultaneous request can be served.

In Linux
Design Models:
A)Offload entire I/O thread pool

  1. User level threads (glibc implementation)
  2. kernel threads

B)Fully Asynchronous state machine each operation

  1. Series of event driven non-blocking steps (example?)
  2. Map user buffer to process context independent form.

C)Hybrid Approach with Split phase I/O

  1. Async. Submission,pool of thread for comletion. (e.g. SGI KAIO)

1) Linux Native AIO APIs (in user space libaio)
a)io_setup()
b) io_destroy()
c)io_submit
d) io_cancel
e)io_getevents

2) Posix APIs based (in user space glibc)
a) aio_read()
b) aio_write()
c) aio_listio()
d) aio_suspend() etc

Linux aiocb block for posix API (glibc)

struct aiocb {
int aio\_fildes; // File Descriptor
int aio\_lio\_opcode; // Valid only for lio\_listio (r/w/nop)
volatile void \*aio\_buf; // Data Buffer
size\_t aio\_nbytes; // Number of Bytes in Data Buffer
struct sigevent aio\_sigevent; // Notification Structure
/\* Internal fields \*/ …
};
Posix AIO notifications available : 1\) Signal (SIGEV\_SIGNAL) 2\) Async callback (SIGEV\_THREAD)

This following link I found explain best of AIO

http://www.ibm.com/developerworks/linux/library/l-async/#iratings

I will later dig more into retry based AIO implementation in kernel level.