ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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).
Distribution: Slackware & Slamd64. What else is there?
Posts: 1,705
Rep:
Quote:
Originally Posted by George2
Hello everyone,
Could anyone help to clarify the differences between the two words?
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.
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.
What API do you men in Linux is asynchronous I/O? select?
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.
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?
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.
Distribution: Slackware & Slamd64. What else is there?
Posts: 1,705
Rep:
Quote:
Originally Posted by George2
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
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.
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?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.