Looking for a real time IPC to be used with select

Looking for a real time IPC to be used with select

[M. Koehrer]

Hi all,

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.
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().

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...

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

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

RE: Looking for a real time IPC to be used with select

[Leyendecker, Robert]

> -----Original Message-----
> From: linux-rt-users-owner@vger.kernel.org [mailto:linux-rt-users-
> owner@vger.kernel.org] On Behalf Of M. Koehrer
> Sent: Friday, April 16, 2010 9:13 AM
> To: linux-rt-users@vger.kernel.org
> Subject: Looking for a real time IPC to be used with select
> 
> Hi all,
> 
> 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.
> 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().
> 
> 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...
> 
> Both, threads A and B are real time threads, thus any IPC in use
> should be supported by the RT_PREEMPT patch.
> 
> Setup: PC (Core2Quad, kernel 2.6.31.2-rt13)
> 
> Thanks for any feedback on this question.
> 
> Regards
> 
> Mathias
> 


You could try pipe() and take a look at epoll(). My testing shows it's reasonably efficient and the epoll() API is quite flexible.  

I've thought about using eventfd() and epoll() for exactly the purpose you mention but haven't had time to try it. 

I've used select(), poll(), epoll(), siqueue(), async i/o, pipes, regular signals, etc (just waiting for the next method that fixes the asynch i/o problem, really, really, this time :-) 

Of all the techniques I've used for network smashing, the async i/o has always been problematic for me. Epoll() seems better. Using a fd for signaling always sort of bothered me but I see it all over the place even for high throughput.

I generally let epoll() time out when it isn't busy and handle messaging at that time. If you are being hammered, you might never service the IPC event, however. For me, that condition is handled by a thread watchdog -or- checking for EINTR. In this case its like a denial of service attack.

All of these (excepting eventfd, which I have not tried) seem to work OK with rt patch although have not tested latest.  

Maybe eventfd() is the "right" way to do it? 

Always a bit nervous about posting stuff like this since everyone has different experience but hope this gives you some useful ideas to work with.


-Bob

Re: Looking for a real time IPC to be used with select

[Armin Steinhoff]

Hi,

have a look to http://www.zeromq.org ... it does probably  what you want.

Armin Steinhoff
---
Armin Steinhoff   <as@Steinhoff-Automation.com>  
STEINHOFF Automation &  Fieldbus-Systems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TEL +49-6431 -529366  or  -570 99 70
FAX +49-6431 - 57454  or  -570 99 80
http://www.steinhoff-automation.com

 

M. Koehrer wrote:
> Hi all,
>
> 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.
> 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().
>
> 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...
>
> Both, threads A and B are real time threads, thus any IPC in use
> should be supported by the RT_PREEMPT patch.
>
> Setup: PC (Core2Quad, kernel 2.6.31.2-rt13)
>
> Thanks for any feedback on this question.
>
> Regards
>
> Mathias
>
>
>
>   

Re: Looking for a real time IPC to be used with select

[Pradyumna Sampath]

On Fri, Apr 16, 2010 at 4:12 PM, M. Koehrer <mathias_koehrer@arcor.de> wrote:

> 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.
> 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().
>
> 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...

POSIX message queues in the kernel work fine for me. I had one problem
with the accuracy of the timeouts in mq_timedreceieve and mq_timedsend
which has been now fixed and is available as part of the latest -rt
patch.

regards
/prady

-- 
http://www.prady.in

Re: Looking for a real time IPC to be used with select

[Sujit K M]

> 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

Re: RE: Looking for a real time IPC to be used with select

[M. Koehrer]

Hi Robert, 

thanks for the reply.

> > 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...
> > 
> > Both, threads A and B are real time threads, thus any IPC in use
> > should be supported by the RT_PREEMPT patch.
> You could try pipe() and take a look at epoll(). My testing shows it's
> reasonably efficient and the epoll() API is quite flexible.  
> 
> I've thought about using eventfd() and epoll() for exactly the purpose you
> mention but haven't had time to try it. 
eventfd() looks very interesting.
I think I will do a test using it.

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

Re: Re: Looking for a real time IPC to be used with select

[M. Koehrer]

Hi Pradyumna,

thanks for this approach!

> > 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...
> 
> POSIX message queues in the kernel work fine for me. I had one problem
> with the accuracy of the timeouts in mq_timedreceieve and mq_timedsend
> which has been now fixed and is available as part of the latest -rt
> patch.
I read again the man page "mq_overview" and found that the message queue descriptor 
could be used with select/poll! That's a point I have not realized so far.
Thus, this allows to use this as another promising approach!
BTW: When I use select() for the timeouts and mq_receive (instead of mq_timedreceive), 
I hope to find no accuaracy issue... 
I think select() is using high accuracy with the timeout in -rt.

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