On Tuesday 22 May 2001 14:38, Goran Bervar wrote:
[...]
> 1) IMO it is always a bad idea to lock the serious RTOS (excluding DOS of
> course <g>) for such a long time. Can somebody explain what would happen
> under RTL if done so?
If you have only one RT thread, there's no problem. The RT thread will hog
the CPU until it's done, and then let "standard Linux" continue where it left
off, just as if it had been handling an IRQ.
BTW, the only problem with "locking" the CPU for extended periods of time
(pretty much regardless of platform), is that you may cause some drivers for
timing sensitive hardware to freak out as a result of missing IRQs. For
example, serial ports without real FIFOs will drop data if you prevent the
driver ISR from running for more than the time it takes to receive one byte.
(Not a big issue with the 16550 chip used in every serious product today,
since they have 16 bytes or more of h/w FIFO space. 16 time more timing
slack.)
> 2) Handling IRQ, I have to make all IO operations before re-enabling
> interrupts.
No hardware buffering/latching + timing? Always lots of fun! *heh*
> I assume after that computation should be made in the highest
> priority task in RT kernel space.
Probably.
> Is anything wrong with such a design?
No, but if the RTL task is going to *return* data to the next interrupt,
you'd better make sure that you don't get sync trouble in that transaction.
> Some better ideas? Link to a similar example?
It would be simpler and safer (in some cases, at least) to just do all the
time critical stuff in the ISR. *However*, if it's going to hog the CPU for
more than some ms per IRQ, you have to consider the effect that might have on
drivers and other stuff you might be using.
Standard Linux and drivers for most hardware shouldn't have much trouble with
losing the CPU for up to several ms, but there *is* crappy hardware (some
software modems and old serial ports, for example) that doesn't have enough
buffering to handle that reliably. Also, you'll wreck the user space real
time performance of a Linux/lowlatency kernel that way. (Your CPU hogging
will add to the latencies of the Linux scheduler.)
> And BTW, how to detect an overdue?
If you just want to know how you're doing in respect to the deadline, you
could query the performance counter (preferably using the RTL API) to see how
close you ore to the next expected interrupt.
If you've just missed it, well... tough luck! ;-) If at that point, the hard
RT stuff is done, and what you're doing less critical, then at least you know
you can sort of "fix" things by separating into ISR + thread, the way you
suggested. You still have to handle the case where the thread lags behind, of
course - as well as the sync issues.
As to more general CPU overload protection:
Simple solution:
1. Set up low priority taks that writes data to a lock-free FIFO,
or just increments a counter or something, periodically.
2. Before the heavy work in every interrupt/cycle, check the FIFO
or counter, to make sure that the lower priority thread is still
alive. (If it doesn't say anything in a "substantial" amount of
time, it's dead - most probably because you're overloading the
CPU.)
Improved solution:
Like the Simple aproach, but use a separate thread to check the low
prio thread. This new thread should have higher priority than any
of the threads you want to keep track of, and should do something
sensible about the situation if it realizes that the low prio thread
is frozen. (This may not be as esay as it sounds...)
The advantages of this method is that you can check a set of threads
(priorities in between those of the "watchdog" threads), and that
you can also protect against endless loops in the watched threads
and similar "system freeze bugs".
> 3) Can I use scheduling instead of IRQ to start the sample? How "accurate"
> is it?
Yes, and it's quite accurate, at least in terms of what you'd use IRQs and
software dependent timing for. Can't tell you any useful figures from the top
of my head, though.
> 4) Communication between threads is something I can not decide how to.
> Taking in account that there is quite some non-critical information from RT
> thread (mostly read-only) that user thread must read often (where the data
> *may* be partly incorrect now and than), what is in your opinion "the best"
> way to do it? Shared memory, FIFOs, messaging...?
Depends a lot on the application.
For high IRQ frequencies and/or extreme timing accuracy demands, it might be
a good idea to avoid disabling IRQs, especially if you have to access the
data from other threads than the highest priority one. (If you have more than
one RTL thread, you may accidentally kill the ISR timing by keeping the IRQs
disabled for too long...) Lock-free single reader - single writer FIFOs are
fast, easy to implement, and very handy in this kind of situations. Properly
implemented, they can also take quite some bandwidth, although you can't
normally avoid the read/write copying overhead.
For higher bandwidths, it might be a good idea to use shared memory. Handle
syncronization using semaphores, spinlocks, RTL FIFOs, lock-free FIFOs,
disabling IRQs, or whatever does the job without excessive complexity. (FIFOs
can be used for passing references to buffers in the shared memory area, for
example. Very simple way of dealing with complex allocation and timing
patterns.)
> 5) I have some problem understanding RT Linux mutexes. Do they include
> priority switch to avoid priority dead locks?
Actually, I'm not sure about the current state. There are oppinions about
this; some say that trying to handle priority inversion is a bad ide, and
only encourages flawed designs, whereas others claim that it's an essential
feature of any multithreaded OS. Personally, I tend to agree with the former
idea, at least for the hard real time part of a system.
Regards,
//David Olofson --- Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> [EMAIL PROTECTED] -'
-- [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/
