Multiprocess I/O

Discussion in 'C Programming' started by seimarao, Feb 22, 2014.

  1. seimarao

    seimarao Guest

    Hi,

    In 'C', if two processes are doing their I/O then is there
    any particular order adhered by the two ?

    Suppose Process P1's I/O takes 5 minutes & Process P2's I/O takes
    10 minutes, then does 'C' allow P1 to complete its I/O before
    P2 even starts given that both start doing at the same time ?

    Sincerely,
    Seima Rao.
     
    seimarao, Feb 22, 2014
    #1
    1. Advertisements

  2. seimarao

    Kaz Kylheku Guest

    In C, if you have two-processes, then your program is very platform-specific.
    There are no "processes" in the C language itself. (Well, 2011 C standard has
    threads now.)
    C does not contain a scheduler; it is not an operating system.

    Your paragraph contains a contradiction. "P1 completes I/O before P2 starts"
    contradicts "given that both start at the same time"

    If P1 and P2 start at the same time, then by logical definition alone, P1
    cannot do anything before P2 starts.

    Please re-phrase your question, and include some C code that compiles and runs
    which demonstrates it, if you believe it to be relevant to the C language
    somehow. What kind of multi-processing or multi-threading library are you
    using; what kind of devices are you doing I/O on. Are the processes sharing the
    same device or doing I/O to independent devices?

    Generally speaking, if the I/O operations are to different devices, and the CPU
    load associated with those operations is light, then their performances
    are quite independent of each other.

    Think about it: does your computer stop playing audio (I/O in process P1) so
    that you can complete copying a file from the hard drive to your SD card (I/O
    in process P2)?

    And what does C have to do with it?
     
    Kaz Kylheku, Feb 22, 2014
    #2
    1. Advertisements

  3. seimarao

    seimarao Guest

    Suppose P1 & P2 start their I/O to the *same* I/O device
    at 0 sec. My 'C' stdio library will buffer both I/O
    ops to memory and then at a "suitable" time decide
    to complete P1's I/O before starting P2's I/O.

    Is this legal 'C' ?

    Sincerely.
     
    seimarao, Feb 22, 2014
    #3
  4. seimarao

    Joe Pfeiffer Guest

    You're going to be getting answers to your questions that frustrate you
    because you're asking what C will do about things C is simply doesn't
    have responsibility for.
    Assuming P1 and P2 are separate processes (on whatever platform you're
    running), they have what amount to two separate instances of the IO
    library. The behavior you're asking about can certainly happen; on the
    other hand, you could in principle see byte-by-byte interleaving or even
    see one process's IO stepped on and obliterated by the other's. None of
    these are legal or illegal C; C just isn't relevant to them.
     
    Joe Pfeiffer, Feb 22, 2014
    #4
  5. seimarao

    Kaz Kylheku Guest

    The c stdio library does not do any such thing. Its output streams
    can be in three modes: unbuffered, line buffered and fully buffered.

    Unbuffered streams do not delay the delivery of data to the operating system.
    Buffered streams accumulate a full buffer, and flush it out to the operating
    system with it fills up. Line buffered streams automatically flush when
    a complete line is accumulated. Buffered streams can be flushed at any time
    with fflush.

    There are no time-related rules.
    If no language extensions are used in the C program, then it is not
    a conforming implementation of stdio FILE * streams to have such a time-based
    scheduling behavior. There can be such a behavior in the underlying operating
    system, however.

    For instance on many operating systems, the system call which outputs data to a
    file can return before that data has been placed in the storage device.
    Meanwhile, I/O to some other device might complete sooner. For instance,
    suppose we write a block to disk, and then immediately print a message on a
    serial console. The serial I/O to the UART might appear on the terminal before
    the disk write is issued. Both write operations, the one to the disk and the
    one to the serial device, can return to the caller before the data actually
    goes out (i.e. without waiting for completion). Which one stays buffered longer
    depends on the speed of the device and the strategy of the software management
    layers above it.

    There may be ways to wait for the completion of I/O if the program needs to be
    sure; the C stdio library doesn't provide such a thing, however.

    In the POSIX environment we can do fsync on a file descriptor. POSIX extends
    FILE * streams with the fileno function, by which you can obtain a file
    descriptor. fsync works for regular files. To wait for pending serial port
    (tty) data to be written, there is another POSIX function: tcdrain.

    These are all extensions to C, not part of standard C.

    If you have multiple processes doing I/O on the same device, that may not even
    be allowed, depending on the device. On Unix-like systems a "single open"
    device will block or reject open calls if it is already open. On some devices,
    concurrent I/O can do silly things, like interleaving the data in such a way
    that it can't be unravelled: like if two processes both spew logging to a
    console. Concurrent random access over record-structured files is possible, if
    the processes agree on some sort of locking, to stay out of each other's way.
     
    Kaz Kylheku, Feb 22, 2014
    #5
  6. seimarao

    Eric Sosman Guest

    C's *only* mechanism for running more than one program
    is the system() call, and C offers no way to synchronize the
    actions of the program that called system() and the program
    launched by system(). Thus, there's nothing in C that can
    "decide" in the way you describe.

    That said, the system on which C is running probably
    provides synchronization mechanisms of some kind or other;
    every O/S that is capable of running more than one program
    has *some* means of keeping them out of each other's hair.
    An O/S might conceivably make some of its synchronization
    available through the system() call, but the only kind I've
    ever encountered is "system() returns after the launched
    program exits." Other kinds are certainly possible, but
    I've never seen them -- and even this fairly basic style is
    implementation-dependent and not mandated by C.
     
    Eric Sosman, Feb 22, 2014
    #6
  7. seimarao

    Ian Collins Guest

    Used for, sure. Responsible for, no. C is used for most ECU software,
    but C isn't responsible for controlling engines.

    How I/O from different processes is scheduled and or interleaved is
    entirely the responsibility of the environment running the processes.
     
    Ian Collins, Feb 22, 2014
    #7
  8. On POSIX systems, the string passed to system() is interpreted by the
    shell /bin/sh, which means all of the Bourne shell's features are
    available. So if a C program executes:

    system("foo &");
    system("bar &");

    or even

    system("foo & bar &");

    then foo and bar can execute in parallel.

    This is all beyond the scope of (but compatible with) the C standard,
    which only says that:

    If `string` is a null pointer, the system function determines
    whether the host environment has a command processor. If
    `string` is not a null pointer, the `system` function passes the
    string pointed to by `string` to that command processor to be
    executed in a manner which the implementation shall document;
    this might then cause the program calling `system` to behave
    in a non-conforming manner or to terminate.
     
    Keith Thompson, Feb 22, 2014
    #8
  9. seimarao

    Geoff Guest

    C doesn't care. C doesn't have any responsibility for or any provision
    for "tasking" if P1 and P2 are two different programs in a system. The
    C library will be invoked in a very system dependent way such that
    your two processes will be granted I/O access via system facilities.

    If P1 and P2 are operating on _different_ I/O objects then there is no
    contention and they can _appear_ to be running simultaneously.

    However, if P1 and P2 are operating on the _same_ I/O object then the
    contention must be resolved by the operating system and this is
    off-topic for C per se. For example if P1 and P2 both try to write to
    the same file there will be a race condition within the operating
    system over who will be granted access to the file and in a modern,
    properly designed OS the winner will be allowed a "lock" on the
    resource until that process closes it.

    But a C program has no knowledge of that activity and if you code a
    program to open and close a resource and you try to code another
    program to open and close that same resource then you will have many
    problems managing that resource.
     
    Geoff, Feb 22, 2014
    #9
  10. seimarao

    Eric Sosman Guest

    ... and system() returns when the launched program (/bin/sh)
    exits. Whatever else /bin/sh may do during its lifetime, the
    caller blocks in system() until /bin/sh itself finishes.
     
    Eric Sosman, Feb 23, 2014
    #10
  11. seimarao

    Ken Brody Guest

    [... multiple processes to a single "I/O device" ...]
    Out of curiosity -- would something like this fall under "undefined
    behavior", or is there such a category as "beyond the scope of the C language"?
     
    Ken Brody, Feb 24, 2014
    #11
  12. seimarao

    Joe Pfeiffer Guest

    To say some behavior is "undefined" in the context of this group just
    means it isn't defined by the C language. There's *lots* of behavior
    that's not defined by C, but is defined elsewhere; maybe by the
    particular compiler you're using, maybe by the OS you're running on,
    maybe somewhere else. So in a sense the answer is "yes", but you won't
    generally find something so tidy as a "defined elsewhere" note.

    I'm sure some of the other people on this group with a better knowledge
    of the standard will clarify this.
     
    Joe Pfeiffer, Feb 24, 2014
    #12
  13. seimarao

    Eric Sosman Guest

    I'd vote for "beyond the scope." 1p2:

    This International Standard does not specify

    — the mechanism by which C programs are transformed for use
    by a data-processing system;
    — the mechanism by which C programs are invoked for use by
    a data-processing system;
    — the mechanism by which input data are transformed for use
    by a C program;
    — the mechanism by which output data are transformed after
    being produced by a C program;
    — the size or complexity of a program and its data that will
    exceed the capacity of any specific data-processing system
    or the capacity of a particular processor;
    — all minimal requirements of a data-processing system that
    is capable of supporting a conforming implementation.

    The second through fourth points seem to cover most of what's
    been discussed in this thread.
     
    Eric Sosman, Feb 24, 2014
    #13
  14. seimarao

    James Kuyper Guest

    No - in order to qualify as undefined behavior, it must be the result of
    the "use of a nonportable or erroneous program construct or of erroneous
    data". That doesn't apply in this case.
    The scope of the C standard is described in section 1. 1p1 lists things
    specified by the standard, and does not include anything covered by this
    issue. 1p2 lists some things NOT covered by the standard, and the second
    item seems somewhat relevant: "the mechanism by which C programs are
    invoked for use by a data-processing system;". However, there is no
    officially defined name for that category.
     
    James Kuyper, Feb 24, 2014
    #14
  15. The volatile identifier was in the C
    standard long time ago.

    The POSIX functions about threadings
    and processes are somewhat vague
    even in 201X.
     
    88888 Dihedral, Mar 2, 2014
    #15
  16. seimarao

    James Kuyper Guest

    That's a little ambiguous - by "that category" I meant the category of
    behavior that is outside the scope of the C standard.
    How is that relevant to this thread?
    Multi-process I/O is within the scope of POSIX, and I thought it was
    sufficiently specific to answer the OP's question (assuming that POSIX
    is the domain of that question).
     
    James Kuyper, Mar 3, 2014
    #16
  17. seimarao

    Tim Rentsch Guest

    I second the comments of Eric Sosman and James Kuyper. The
    term "undefined behavior" applies only to constructs that
    are part of the C language, and considered in the context
    of a C program. What happens when a Pascal compiler tries
    to compile or run a program, even if the program source
    is C code, is neither "defined behavior" nor "undefined
    behavior" as the Standard uses the terms. The Standard
    does not consider the notion of "process" at all, except
    non-normatively in a Note (7.17.5 p2); how processes
    might interact is therefore neither defined nor undefined
    but simply outside of what the Standard considers.
     
    Tim Rentsch, Mar 9, 2014
    #17
  18. Don't you model digital systems
    by asyn-I/O and syn-I/O carefully
    in any digital design?
     
    88888 Dihedral, Mar 9, 2014
    #18
  19. seimarao

    James Kuyper Guest

    I"m not sure what you mean by that, except that if you think that it
    implies that multi-process IO should fall inside the scope of the C
    standard, you're quite mistaken. It doesn't describe a multi-process
    machine at all, and therefore says nothing about how I/O associated with
    different process is or is not synchronized.

    Other standards which do address multi-process systems (such as, for
    example, POSIX) do address such issues, and C can be used on systems
    conforming to such standards to perform such I/O - but the issues raised
    by that possibility are not addressed by the C standard itself.
     
    James Kuyper, Mar 10, 2014
    #19
  20. OK, lets be practical to consider
    a memory loacation which can be
    modified by more than one writer
    indepently and the value of the
    memory location stored will be used
    by several readers from time to time
    to perform updates of other computations in a system.


    One will conclude that the ASYN and SYN rules for I/O RW operations must
    be established first before designing a true working digital system.
     
    88888 Dihedral, Mar 11, 2014
    #20
    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.