linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sujit K M <sjt.kar@gmail.com>
To: "M. Koehrer" <mathias_koehrer@arcor.de>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: Looking for a real time IPC to be used with select
Date: Sun, 18 Apr 2010 10:13:25 +0530	[thread overview]
Message-ID: <h2v921ca19c1004172143qbd48d15axe1ba6c2a9f6a35fd@mail.gmail.com> (raw)
In-Reply-To: <3215024.1271427173625.JavaMail.ngmail@webmail08.arcor-online.net>

> I have a real time application with a couple of threads.
> One thread is waiting on a select() call (with timeout)
> for data coming in from a UDP Ethernet socket.
> Once it gets data it does some computation and finally
> leads to the writing of data on the UDP socket.
>
> The (simplified) code for this real time thread is:
>
> void *thread_func_A(void *arg)
> {
>  while (1)
>  {
>     rc = select(...); // Read socket with timeout_value);
>     if (rc > 0)
>     {
>        recv(.., data, .. ); // recv data from socket
>        compute(data, data2);       // Compute data and modify them to data2
>        send(..., data2, ...); // Send data2 to socket
>     }
>   }
> }
>
> This works fine.
>
> Now I have the need that another real time thread B should also be able
> to trigger the "select()" in the thread_func_A() above.

You mean you want to timeout the thread_func_A() Select.

From the Select Man Page as Quoted Below(http://linux.die.net/man/2/select)

(iii)

select() has no sigmask argument, and behaves as pselect() called with
NULL sigmask.

Three independent sets of file descriptors are watched. Those listed
in readfds will be watched to see if characters become available for
reading (more precisely, to see if a read will not block; in
particular, a file descriptor is also ready on end-of-file), those in
writefds will be watched to see if a write will not block, and those
in exceptfds will be watched for exceptions. On exit, the sets are
modified in place to indicate which file descriptors actually changed
status. Each of the three file descriptor sets may be specified as
NULL if no file descriptors are to be watched for the corresponding
class of events.

> This means, I should add a suitable inter-process-communication
> between thread A and B that can be used with select() as well.
> Having this, the thread A can be triggered by the socket or
> by the IPC from thread B by adding two file desciptors to the readfds
> of select().

This might be helpfull as said above.

> My question is now: What kind of IPC is preferred here?
> The only IPC I see is a local socket communication, however
> this looks like a huge overhead for triggering...

I think it is quite possible to use the regular IPC Data structures on Linux.

> Both, threads A and B are real time threads, thus any IPC in use
> should be supported by the RT_PREEMPT patch.

Not quite sure what you mean by this. The RT_PREEMPT Patch Does change
according to the IPC or the Related RT Functions.

>
> Setup: PC (Core2Quad, kernel 2.6.31.2-rt13)
>
> Thanks for any feedback on this question.
>
> Regards
>
> Mathias
>
>
>
> --
> Mathias Koehrer
> mathias_koehrer@arcor.de
>
>
> Traumziele - von Beschreibung bis Buchung jetzt kompakt auf den Reise-Seiten von Arcor.de! http://www.arcor.de/rd/footer.reise
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
-- Sujit K M

blog(http://kmsujit.blogspot.com/)
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2010-04-18  4:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-16 14:12 Looking for a real time IPC to be used with select M. Koehrer
2010-04-16 20:30 ` Leyendecker, Robert
2010-04-17  7:55 ` Armin Steinhoff
2010-04-17 14:42 ` Pradyumna Sampath
2010-04-18  4:43 ` Sujit K M [this message]
2010-04-19  6:24 ` M. Koehrer
2010-04-19  6:31 ` M. Koehrer

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=h2v921ca19c1004172143qbd48d15axe1ba6c2a9f6a35fd@mail.gmail.com \
    --to=sjt.kar@gmail.com \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mathias_koehrer@arcor.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).