Ming Li wrote:
(...)
> I have several questions now. I am trying to understand
> how the RTFIFOs work. Assume a RTFIFO is set up and a RT
> process will write data into it, a non-RT process will
> read the data. If the RT-fifo is empty, the non-RT process
> will be blocked. When the RT write process write data
> into the RT-fifo, the blocking process should be waked up.
> I looked at the code, it seems to me that the rtf-put
> function will put a wake-up task into the tq-rt; and this
> wake-up task will be run when the linux scheduler is
> run, thus wake up the blocking non-RT process. Is this
> correct?
Yes. The RT task sets a flag for the FIFO it writes to, and then
schedules a standard Linux bottom half to wake up all flagged FIFOs.
(That is, if there are several tasks to wake up at once, there's still
just one bottom half IRQ call.)
> I found an article in the newsgroup archive which asked a
> way to send signals to a non-RT process to notify it that
> a RT-process has written someting into the RT-fifo. If the
> above is correct, why do we still need a mechanism to notify
> the non-RT process about the status of the RT-fifo?
For non-blocking I/O, I suppose... You may want to have the user space
task running constantly, but still have a way of synchronizing with the
RT task.
> However, sending signals from a RT process to a non-RT
> process is still very useful. Is there a simple way to
> implement this kind of signal sending?
Don't know. Haven't looked into this yet. (I'll probably study the
kernel code when I give protected memory/user space RT scheduling a
shot. Will need some solution for that sooner or later.)
> The other question is when the linux scheduler is executed?
> Is it executed every time the control is switched back to the
> linux kernel? And is it executed immediately after the
> control switch or it will wait until the next scheduling
> point?
Next scheduling point. Basically, RTLinux preempts Linux when required
(triggerd by hard IRQs), and then switches the Linux context back in
when there's no more RT threads or IRQ handlers to run. It doesn't
change the standard Linux scheduling. That would break the entire
kernel, as Linux doesn't handle full kernel preemption.
//David
--- [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/
