On Wed, Sep 29, 1999 at 07:50:48PM +0900, Sung-Gwan Heo wrote:
> Current POSIX API of RT-Linux seems to miss interprocess
> communication(e.g message passing) and process synchronization
> (e.g semaphore) mechanism.
RTLinux has, for a long time, included Jerry Epplin's semaphore package
as part of the distribution. As soon as someone yells loud enough, I will
add a fast mutex package to the distribution too -- we have a nice
and easy to implement design I think, but it's not been at the top
of the list.
I'm reluctant to incorporate too much as part of the RTL default package
because not everyone needs it, and we don't want to slow down the critical
parts of the system with features that may or may not be needed.
> I think IPC and synchronization are essential to real-time
> application. Needless to say, the message passing time and
> semaphore shuffling time should be deterministic.
>
> Is there good method in RT-Linux2 to do IPC and synchronization?
There is the obvious: shared memory and the spinlock/ interrupt control
components -- which I should describe in the design doc!
In some ways, I think mailboxes are so simple that it is better to have
application specific mailboxes if you want them.
Part of the question here depends on what you are doing. If you are porting
some "rt" SGI application to RTLinux, you may need emulation of all the
inherently soft RT features that people use in such applications. If
you want "pedal to the metal" realtime, you really don't want to blow your
cache or sink into a (God forbid) priority inheritance unit.
RTLinux wants to allow you to write slow code if you insist, but we don't
want to force you to do so.
The interesting part of the design is trying to find the optimal balance.
Clealry, my idea of optimal balance is not the same as those of the
designers of some other RTOSs in that I am far more reluctant to add
features. So, for example, part of the RTLinux design is to make sure that
the scheduling module is always replaceable and to make sure that other modules
do not depend too much on the design of the scheduling module. Many
other RTOS designs make the scheduling module central.
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
