Inter-process communication for real-time - Embedded

This is a discussion on Inter-process communication for real-time - Embedded ; For my Arm9 board, my application will have 2 or 3 processes or maybe threads and one of ( pipe, socket, fifo, msg queue or shared memory, or?) to pass data between them. The data is about 100bytes every 50ms. ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Inter-process communication for real-time

  1. Inter-process communication for real-time

    For my Arm9 board, my application will have 2 or 3 processes or maybe
    threads and one of ( pipe, socket, fifo, msg queue or shared memory,
    or?) to pass data between them. The data is about 100bytes every 50ms.
    Assuming I just have vanilla Linux or uCLinux without any real-time
    enhancements, which of the above methods will have the least processor
    overhead, so as to be a bit closer to meeting real-time deadlines?

    My guess is that pthreads with shared memory might be best, but maybe not.

  2. Re: Inter-process communication for real-time

    tns1 wrote:
    > For my Arm9 board, my application will have 2 or 3 processes or maybe
    > threads and one of ( pipe, socket, fifo, msg queue or shared memory,
    > or?) to pass data between them. The data is about 100bytes every 50ms.
    > Assuming I just have vanilla Linux or uCLinux without any real-time
    > enhancements, which of the above methods will have the least processor
    > overhead, so as to be a bit closer to meeting real-time deadlines?
    >
    > My guess is that pthreads with shared memory might be best, but maybe not.


    On ARM you should use one process with more than one thread for this job.
    Changing between processes hurts the ARM CPU as it needs to throw away its
    cache content for *each* change (cache works on virtual address lines
    instead physical ones)!
    For example on an Xscale running at ~500MHz you can wake up one process in
    your system every 100us (with HRT and RT Preempt). But with only one
    additional process in the system it does not work anymore. The time
    increases to 300us ... 500us (changing priority in this case does not help,
    as this is a hardware restriction).

    JB

  3. Re: Inter-process communication for real-time

    Juergen Beisert wrote:
    > tns1 wrote:
    >> For my Arm9 board, my application will have 2 or 3 processes or maybe
    >> threads and one of ( pipe, socket, fifo, msg queue or shared memory,
    >> or?) to pass data between them. The data is about 100bytes every 50ms.
    >> Assuming I just have vanilla Linux or uCLinux without any real-time
    >> enhancements, which of the above methods will have the least processor
    >> overhead, so as to be a bit closer to meeting real-time deadlines?
    >>
    >> My guess is that pthreads with shared memory might be best, but maybe not.

    >
    > On ARM you should use one process with more than one thread for this job.
    > Changing between processes hurts the ARM CPU as it needs to throw away its
    > cache content for *each* change (cache works on virtual address lines
    > instead physical ones)!
    > For example on an Xscale running at ~500MHz you can wake up one process in
    > your system every 100us (with HRT and RT Preempt). But with only one
    > additional process in the system it does not work anymore. The time
    > increases to 300us ... 500us (changing priority in this case does not help,
    > as this is a hardware restriction).
    >
    > JB


    So what about sharing data between the threads? In the past I have used
    message queues, but I suspect they use more processor time than say, a
    shared memory or pipe. I'd like to start off with the right architecture
    since I don't have time to test all the possible configurations.

  4. Re: Inter-process communication for real-time

    tns1 wrote:

    > Juergen Beisert wrote:
    >> tns1 wrote:
    >>> For my Arm9 board, my application will have 2 or 3 processes or maybe
    >>> threads and one of ( pipe, socket, fifo, msg queue or shared memory,
    >>> or?) to pass data between them. The data is about 100bytes every 50ms.
    >>> Assuming I just have vanilla Linux or uCLinux without any real-time
    >>> enhancements, which of the above methods will have the least processor
    >>> overhead, so as to be a bit closer to meeting real-time deadlines?
    >>>
    >>> My guess is that pthreads with shared memory might be best, but maybe
    >>> not.

    >>
    >> On ARM you should use one process with more than one thread for this job.
    >> Changing between processes hurts the ARM CPU as it needs to throw away
    >> its cache content for *each* change (cache works on virtual address lines
    >> instead physical ones)!
    >> For example on an Xscale running at ~500MHz you can wake up one process
    >> in your system every 100us (with HRT and RT Preempt). But with only one
    >> additional process in the system it does not work anymore. The time
    >> increases to 300us ... 500us (changing priority in this case does not
    >> help, as this is a hardware restriction).

    >
    > So what about sharing data between the threads? In the past I have used
    > message queues, but I suspect they use more processor time than say, a
    > shared memory or pipe. I'd like to start off with the right architecture
    > since I don't have time to test all the possible configurations.


    Sharing data between threads is always the most efficiency way. The POSIX
    message queues are also part of the POSIX realtime library. But: Don't use
    the IPC implementations of sharing memory and message queues!

    Note: To benefit from the new kernel features you need a very recent EABI
    toolchain for ARM. OABI toolchains do not help.

    JB

  5. Re: Inter-process communication for real-time


    > My guess is that pthreads with shared memory might be best, but maybe not.


    If you can accept a "might be best" solution, this is soft realtime and
    not hard realtime. Thus you are fine with Linux.

    If you need a "must happen before..." solution this is hard realtime and
    Linux will not suite you.

    -Michael

  6. Re: Inter-process communication for real-time

    > On ARM you should use one process with more than one thread for this job.
    > Changing between processes hurts the ARM CPU as it needs to throw away its
    > cache content for *each* change (cache works on virtual address lines
    > instead physical ones)!


    This is true for "full" MMU Linux. If you use µCLinux, this ARM problem
    is not triggered and the (soft) realtime performance will be better.

    -Michael

  7. Re: Inter-process communication for real-time

    Of course with µCLinux sharing data between processes is really simple .

    -Michael

+ Reply to Thread