asynchronized I/O == multiplexing I/O?
 

Hello everyone,


I always see the two words -- asynchronized I/O and I/O multiplexing. Are they the same thing -- like select/poll?

I noticed that in some situations, people say they are different and asynchronized I/O is better than I/O multiplexing.

Could anyone help to clarify the differences between the two words?


thanks in advance,
George

Yes, asynchronous I/O == multiplex I/O.

The terms apply to the same technique, but applied to different contexts. The term "asynchronous I/O" is usually used in device I/O (for example, a hard drive). The term "multiplex I/O" usually applies to a software implementation (for example socket programming).

Same concept, different perspective.

The answer is really "Yes", "No" or "Maybe" ... depending on the context.

"Asynchronous I/O" (not "asynchronized"!) requires kernel support.

On the other hand, "select/poll" (which *appears* to be asynchronous, from the user-space perspective) doesn't.

Both permit multiplexing; only true "asynchronious I/O" can actually increase system throughput (as opposed to perceived responsiveness).

Here are some links on "true asynchronous I/O", for Linux ("aio()" and friends) and Windows (which has "I/O Completion Ports" in Win2k and above):

http://lse.sourceforge.net/io/aio.html
http://www.ixora.com.au/notes/fs_asynchronous_io.htm
http://www.ixora.com.au/notes/raw_asynchronous_io.htm
http://www.codeproject.com/internet/...ableServer.asp

Some explanations of these terms:

Asynchronous request processing (of whatever type) means that you can continue doing work after issuing a request for service. This is as opposed to a synchronous request, which doesn't return control to the caller until it finishes fulfilling the request. The purpose of this is to give you some overlap in processing. It works most effectively if you have more than one CPU or an I/O controller that works independently of the CPU (in the case of an I/O request) otherwise you're just splitting your work up into pieces and contending with yourself for CPU cycles. (Even that is not as bad as it sounds- when the CPU is fast enough it enables an OS like Linux to be responsive in an X-Windows environment while you're also running other apps, for example.)

To understand asynchronous I/O from the coder's point of view: you could issue a request for a record from a data base, continue doing some work, and then at a convenient time, check to see if the request has completed.

If you had issued a synchronous request, your code would not go further until the request was completed.

Asynchronous services offer significant performance advantages in multiprocessing configurations (more than one CPU) but the coding is more complicated than using synchronous requests because you have to check to see if the request has completed and deal with errors after they occur.

Multiplexing just means "many into one." I haven't heard it applied to I/O at the API level.

Maybe you meant multithreading? This is how asynchronous I/O typically gets implemented. What it means is that one (or more) work units are assigned to run your program code under, and one (or more) work units are assigned to run your I/O request under. This is the way that the OS manages the job of giving time and other resources to different work on the system. As with asynchronous processing generally, multithreading is nice but it starts to offer significant performance advantages when you have more CPUs to run work under.

Thank you paulsm4,


select is not true asynchronous I/O? How do you make such conclusion -- how select is implemented to be a fake asynchronous I/O? :-)


regards,
George

Hello macemoneta,


What API do you men in Linux is asynchronous I/O? select?


regards,
George

Thank you Randux,


Very fruitful answer! Do you mean function like select when you are talking about asynchronous I/O? Any other asynchronous I/O API or libraries?


regards,
George

Hi -

The problem is confusion between several (completely different!) meaning of the term "asynchronous".

"Asynchronous" can be a general term; it can also mean something very specific.

In the general sense: "Yes, 'select()' allows you to respond 'asynchronously'".

In the specific sense: "No: 'select()' is not an 'asynchronous' API ... but 'aio_read()' is."

Yes: standard sockets and file streams can be made to read asynchronously (using 'setsockopt()' and 'ioctl()', respectively) ... but this is NOT really an example 'asynchronous I/O'.

Yes, you can multiplex different blocking I/O streams using 'select()', but this isn't really 'asynchronous I/O' (in the specific sense), either.

BOTTOM LINE:
It can mean different things, depending on the context.

This article explains it much better:
http://www.artima.com/articles/io_design_patternsP.html

SUGGESTED TERMINOLOGY:
To avoid confusion, perhaps it might be easier to use this terminology instead:

1) Blocking, or non-blocking synchronous:
select() etc: "standard" I/O; no special kernel support needed

2) Non-blocking asynchronous
aio: a special high-performance technique, supported by Linux and Windows kernels

'Hope that helps .. PSM

Sorry, George, I am not knowledgeable about *NIX internals and facilities, so I can't answer your questions. I'm sure other guys here can help.

exciting exploration
 

In my opinion asynchron IO != multiplexed IO
When you need multiplexed IO you simply want to be informed about IO events on several IO channels (such as socket, serial or parallel, even file such as fifos, pipes). In other side several asynchron IO could be multiplexed, but multiplexing could not be asynchroned. Another side that all of these things about how to avoid waiting for a specific IO operation and do not missing other, in the same time keep synchronized with every events.
For me today, this discussion is interesting because after progz I can not integrate IO multiplexing, signal handling and timers in convenient way, to keep good modularity of the C code!;o(
First time I simply ignored the signals and timers, use a simple select multiplexer inside the working thread, putting/pulling packets to be read/write into a threadsafe FiFo (exactly a double linked list) and using select's timeout timer to have more or less precise timer. After I'm trying liboop - nice, but does not support threads! In result every time I need to write new code to "low" level communication handling! Seem to be I've should write my own wrapper for these purposes?