All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Andrey Nechypurenko <andreynech@domain.hid>
Cc: Xenomai help <xenomai@xenomai.org>
Subject: Re: [Xenomai-help] Communication between RT and non-RT thread
Date: Wed, 06 Jul 2011 14:19:47 +0200	[thread overview]
Message-ID: <4E1452E3.4010107@domain.hid> (raw)
In-Reply-To: <CAOiXNkARoeBWpSRQtkh8OLye3AYGtX8qcD1-K-zNO8ooPW0sBA@mail.gmail.com>

On 07/06/2011 01:42 PM, Andrey Nechypurenko wrote:
> Thanks Gilles for the quick response!
> 
>> You can use mutexes with priority inheritance to avoid this issue. But
>> Xenomai has ready made queues for rt/non-rt communication, the rtipcs:
>>
>> http://www.xenomai.org/documentation/xenomai-head/html/api/group__rtipc.html
> 
> What makes me worry here is the IPC abbreviation - I have just one
> process with multiple threads. So would not real IPC mechanism be the
> overkill in this scenario? Or am I just misinterpret what IPC means
> here?

Not really overkill. Data will be copied from and to an intermediate
buffer. But if you send pointers to data, these copies will simply
involve copying the pointer twice.

I would say it is lockless mechanism which are overkill. Because
usually, lockless mechanisms have a much more complicated
implementation, and so are much more prone to bugs. All this for what?
To avoid a small critical section?

> 
>> A lockless solution for this (one consumer, one producer) is the good
>> old fifo.
> 
> I have one producer, but do not want to limit myself with just one
> consumer (although currently there is only one). In addition, here I
> am probably again confused by the terminology, but does not fifo you
> mentioned here is another IPC mechanism? What I am seeking is the way
> to communicate between two threads and benefit from the fact that they
> share the same process memory.

I am talking about the ring buffer thing with head and tail pointers
where each thread (consumer, producer), moves only one pointer. I would
call this a "lockless fifo", though I do not know what the official name
is, but you get the idea. Again, you can send pointers through an IPC
instead of sending the data themselves, and you will benefit from the
fact that the two threads are running in the same memory space.

-- 
					    Gilles.


  reply	other threads:[~2011-07-06 12:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-06  9:25 [Xenomai-help] Communication between RT and non-RT thread Andrey Nechypurenko
2011-07-06 11:22 ` Gilles Chanteperdrix
2011-07-06 11:42   ` Andrey Nechypurenko
2011-07-06 12:19     ` Gilles Chanteperdrix [this message]
2011-07-07  7:31       ` Richard Cochran
2011-07-07  7:57         ` Anders Blomdell
2011-07-07  8:44           ` Andrey Nechypurenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E1452E3.4010107@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=andreynech@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.