1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Asynchronous I/O problems and Operating systems

Discussion in 'Embedded' started by ssubbarayan, Sep 19, 2007.

  1. ssubbarayan

    ssubbarayan Guest

    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
     
    ssubbarayan, Sep 19, 2007
    #1
    1. Advertisements

  2. ssubbarayan

    Simon Wright Guest

    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).
     
    Simon Wright, Sep 19, 2007
    #2
    1. Advertisements

  3. ssubbarayan

    CBFalconer Guest

    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.
     
    CBFalconer, Sep 20, 2007
    #3
  4. ssubbarayan

    Simon Wright Guest

    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!
     
    Simon Wright, Sep 20, 2007
    #4
  5. ssubbarayan

    ssubbarayan Guest

    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?
     
    ssubbarayan, Sep 21, 2007
    #5
  6. 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
     
    Paul Keinanen, Sep 21, 2007
    #6
  7. 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".
     
    Everett M. Greene, Sep 21, 2007
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.