1. Home
  2. Embedded Programming
  3. Asynchronous I/O problems and Operating systems

Asynchronous I/O problems and Operating systems

Hi all,

1)I was reading in wikipedia about asynchronous I/O.There was a statement like this regarding how asynchronous I/O are supported in OS level in Unix: ========================= Process Available in early Unix. With a multitasking operating system each I/O flow can be allocated to a separate (sub)process. This is a heavyweight solution, and coordinating the flows can be difficult. Because of the natural process isolation it may not even be possible to get the desired behavior; the attempt to partition the task for asynchronous I/O may do more harm than good. ==========================================================

I am not able to realise how this sort of design will do more harm?Do people here who have used such a design faced any problems?

2)When we say asynchronous in OS perse,I would like to understand what conditions need to be met to say a system is asynchronous.I am also aware of using signals and events in some of RTOS.Heard that they are facilties provided by OS to realise asynchronous operations.With respect to this,lets take one example where there are many tasks(not a real one): I have task1.Inside this task I raise a signal(software signal) to another task,when ever My count completes 10. The signal handler is supposed to reset the counter value to zero after doing couple of operations like either turning on a motor and so on. How can we say this is asynchronous?The term asynchronous means OS does not wait on any I/O operations meaning,except the task or process involved in the I/O transaction,other tasks process can continue their work without blocking the CPU.In the above example given,I am not able to realise how other tasks can execute when my counter has not finished counting ten,I believe in this aspect,unless a task releaves a CPU other tasks will not execute.So this makes me wonder whether asynchronous systems are created by design and not by an explicit requirement on the system itself.Is this correct?

I have cross posted in comp.realtime also to gather more views on this topic.

Looking farward for your replies and advanced thanks for the same,

Regards, s.subbarayan

Reply to
ssubbarayan
Loading thread data ...

Unless that other task has a higher priority than task1 it will be unable to run, because task1 is hogging the cpu.

We wouldn't say it's asynchronous, we'd say it's broken!

To me, asynchronous i/o is i/o that happens outside the thread of control that requests the i/o.

If I say

Discrete_IO.Set (Pin, True);

it would probably be sensible for the underlying system to go straight to the indicated pin and set it to logic 1.

If I say

Socket.Send (To => My_Socket, Message => "hello world");

it would be likely that the message would get put into a buffer and handed over to the TCP/IP subsystem for processing (asynchronously) when it gets to the top of the queue.

If I put this in an endless loop the Send call is going to block when the buffering is full (or maybe I'll get an exception, Would_Block perhaps).

Reply to
Simon Wright

Not so. Task2 will run whenever Task1 has nothing to do. These are tasks, not procedural levels. You just have to be careful what Task1 does before Task2 is done. And that Task2 operation doesn't disturb Task1.

--
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
Reply to
CBFalconer

I didn't quote the bit where the OP said

"In the above example given,I am not able to realise how other tasks can execute when my counter has not finished counting ten,I believe in this aspect,unless a task releaves a CPU other tasks will not execute."

which seemed to me to indicate that task1 was spinning -- if not, eg

loop do stuff; post signal; delay 0.001; end loop;

I don't see why the OP would have had a problem!

Reply to
Simon Wright

Hi, Thanks to both you and CBF.I am still not clear what problem would occur when I go for design as stated in point number 1 in my posting? Requoting the problem:

1)I was reading in wikipedia about asynchronous I/O.There was a statement like this regarding how asynchronous I/O are supported in OS level in Unix: ========================= Process Available in early Unix. With a multitasking operating system each I/ O flow can be allocated to a separate (sub)process. This is a heavyweight solution, and coordinating the flows can be difficult. Because of the natural process isolation it may not even be possible to get the desired behavior; the attempt to partition the task for asynchronous I/O may do more harm than good. ==========================================================

I am not able to realise how this sort of design will do more harm?Do people here who have used such a design faced any problems?

Reply to
ssubbarayan

In the late 1970's and early 80's I was mostly working with RSX-11 with 256 KiB of memory and the system had a decent asynchronous I/O (QIO). Each application was divided to at least a half a dozen tasks, each of which relying heavily on asynchronous I/O.

A colleague suggested using Unix, but after reviewing the situation, I concluded that several dozens of processed would have been needed and since at least 8 KiB would have been required for each process on the PDP-11, I concluded that Unix is just a toy.

I later had to change my attitude this century, since at least Linux has a half decent threading library.

Paul

Reply to
Paul Keinanen

And all you have to do is explain to the boy (in 25 words or less) the difference among "task", "process", "thread", and "asynch I/O".

Reply to
Everett M. Greene

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.