The design of 'fast' IPC communication in Linux
Bin Chen
Current I need to design a event dispatcher process that can deliver
the system-wide events to specific process. The dispatcher is a daemon
with a client library used by the processes that receive the event.
The real-time feature of the event will eventually affect the
performance of the overall system for some critical events, so the
dispatcher need to deliver some urgent event very fast(or as faster as
possible).
The event should be always handled in async way(for RT issue) in
client side, so the signal machnism is the only way. I know Linux has
various signal that is for user extending, such as SIGUSR[1|2], and
has RT signals as well. Basically, is the RT signal always make the
signal delivery faster?
Thanks.
ABAI
Steve Watt
Bin Chen <binar...@gmail.com> wrote:
>The real-time feature of the event will eventually affect the
>performance of the overall system for some critical events, so the
>dispatcher need to deliver some urgent event very fast(or as faster as
>possible).
What kind of hard real-time deadlines are you after?
Mantra of hard RT systems everywhere: Real-Time != Real-Fast. If you
want true, hard determinism, you will trade off performance.
>The event should be always handled in async way(for RT issue) in
>client side, so the signal machnism is the only way. I know Linux has
>various signal that is for user extending, such as SIGUSR[1|2], and
>has RT signals as well. Basically, is the RT signal always make the
>signal delivery faster?
"Realtime signals" have nothing to do with speed of signal delivery.
They acquired the name "realtime" because the queued signal system was
specified with the other POSIX 1003.1b "Realtime" extensions. All
the SIGRTMIN-SIGRTMAX signals provide is queueing and an itsy bit of
data. For queueing, when you send 10 of them, you receive 10 of them,
in marked contrast to normal signals. For itsy amounts of data, see
the sigval union.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3"
Internet: steve @ Watt.COM Whois: SW32-ARIN
Free time? There's no such thing. It just comes in varying prices...
Bob Smith
> Current I need to design a event dispatcher process that can deliver
> the system-wide events to specific process. The dispatcher is a daemon
> with a client library used by the processes that receive the event.
D-Bus might be able to help. If you're looking for an IPC
to use in your library, you might take a look at /dev/fanout.
It is a "one-to-many" multiplexer and was made to be a
syslog target. It is at http://www.linuxtoys.org
hope this helps
Bob
Bin Chen
> In article <1170568855.781145.60...@v33g2000cwv.googlegroups.com>,
>
> Bin Chen <binary.c...@gmail.com> wrote:
> >The real-time feature of the event will eventually affect the
> >performance of the overall system for some critical events, so the
> >dispatcher need to deliver some urgent event very fast(or as faster as
> >possible).
>
> What kind of hard real-time deadlines are you after?
>
> Mantra of hard RT systems everywhere: Real-Time != Real-Fast. If you
> want true, hard determinism, you will trade off performance.
>
> >The event should be always handled in async way(for RT issue) in
> >client side, so the signal machnism is the only way. I know Linux has
> >various signal that is for user extending, such as SIGUSR[1|2], and
> >has RT signals as well. Basically, is the RT signal always make the
> >signal delivery faster?
>
> "Realtime signals" have nothing to do with speed of signal delivery.
> They acquired the name "realtime" because the queued signal system was
> specified with the other POSIX 1003.1b "Realtime" extensions. All
> the SIGRTMIN-SIGRTMAX signals provide is queueing and an itsy bit of
> data. For queueing, when you send 10 of them, you receive 10 of them,
> in marked contrast to normal signals. For itsy amounts of data, see
> the sigval union.
The webpage give me some info:
http://www.die.net/doc/linux/man/man7/signal.7.html
3.
Real-time signals are delivered in a guaranteed order. Multiple
real-time signals of the same type are delivered in the order they
were sent. If different real-time signals are sent to a process, they
are delivered starting with the lowest-numbered signal. (I.e., low-
numbered signals have highest priority.)
At least it has priority.
Chris Thomasson
news:1170568855....@v33g2000cwv.googlegroups.com...
> Hi,
>
> Current I need to design a event dispatcher process that can deliver
> the system-wide events to specific process. The dispatcher is a daemon
> with a client library used by the processes that receive the event.
>
> The real-time feature of the event will eventually affect the
> performance of the overall system for some critical events, so the
> dispatcher need to deliver some urgent event very fast(or as faster as
> possible).
Read this for some info on efficient lock-free queuing in a real-time
system:
http://groups.google.com/group/comp.arch/msg/5dba6fee05aa07ea
http://groups.google.com/group/comp.sys.super/msg/642b6b608294e426
(last paragraph...)
Basic idea is to use loopless lock-free algorithms for real-time systems...
See, loopless means that only X amount of instructions are going to be
executed for any one call, period. This information is essential for a
real-time system! Therefore, any loopbased lock-free algorithm is a no-go
wrt any rt system... One more thing... Not only should the algorithm be
loopless, but it should not require the need to call any interlocked rmw
instructions... These are too expensive for a RT system to be executing!
IMHO of course...
;^)
Any thoughts?
Loic Domaigne
I would consider dedicating a thread that waits synchronously for the
messages. You could give the application the chance to specify their
requirements regarding the message delivery by allowing it to specify
the scheduling class / priority of this receiver thread.
If doable, this solution will be less messy to implement and to
maintain.
HTH,
Loic.
Steve Watt
You can certainly do hard RT with spinlocks or regular mutexes, so
there's no need for loopless lock-free. But it certainly makes life
simpler from a deadline analysis standpoint.
When you're using regular locking mechanisms, you need to add the
longest lock-held times of all higher-priority threads plus the longest
lock-held time of any of the lower-priority threads. A not-trivial
exercise.
Chris Thomasson
news:eqbprr$15rg$1...@wattres.Watt.COM...
> In article <lsSdnQPQge60RlrY...@comcast.com>,
> Chris Thomasson <cri...@comcast.net> wrote:
>>"Bin Chen" <binar...@gmail.com> wrote in message
>>news:1170568855....@v33g2000cwv.googlegroups.com...
>>Read this for some info on efficient lock-free queuing in a real-time
>>system:
>>
>>http://groups.google.com/group/comp.arch/msg/5dba6fee05aa07ea
>>
>>http://groups.google.com/group/comp.sys.super/msg/642b6b608294e426
>>(last paragraph...)
>>
>>Basic idea is to use loopless lock-free algorithms for real-time
>>systems...
[...]
> You can certainly do hard RT with spinlocks or regular mutexes, so
> there's no need for loopless lock-free.
Well, thats true.
> But it certainly makes life simpler from a deadline analysis standpoint.
Also true! ;^)
> When you're using regular locking mechanisms, you need to add the
> longest lock-held times of all higher-priority threads plus the longest
> lock-held time of any of the lower-priority threads. A not-trivial
> exercise.
Indeed. FWIW, you can implement a efficient thread-to-thread message
multiplexing algorithm based on 100% loopless lock-free algorithms on any
architecture that has atomic loads/stores, something like a #StoreStore
barrier and dependant loads. Of course you can use #LoadLoad if the arch
doesn't support load-depends; think of the Alpha. Absolutely perfect for
Hard RT systems! :^)
Bilgeha...@gmail.com
> > But it certainly makes life simpler from a deadline analysis standpoint.
>
> Also true! ;^)
>
> > When you're using regular locking mechanisms, you need to add the
> > longest lock-held times of all higher-priority threads plus the longest
> > lock-held time of any of the lower-priority threads. A not-trivial
> > exercise.
>
> Indeed. FWIW, you can implement a efficient thread-to-thread message
> multiplexing algorithm based on 100% loopless lock-free algorithms on any
> architecture that has atomic loads/stores, something like a #StoreStore
> barrier and dependant loads. Of course you can use #LoadLoad if the arch
> doesn't support load-depends; think of the Alpha. Absolutely perfect for
> Hard RT systems! :^)
Hi,
Do you have any pointers to papers that describe lock-free algorithms
with regard to real-time systems? The usenet links are a nice read,
but not enough for complete understanding. Any comparison of lock-free
algorithms to spinlock/mutex scheme for real-time use?
Thanks,
Bahadir
remi.ch...@gmail.com
"It is widely anticipated that one of the next releases of the 2.6
kernel will include two new system calls, tee() and splice(). "
So you may consider this:
http://kerneltrap.org/node/6505