On Saturday 10 November 2001 22:54, G�rard LASSAILLY wrote:
[...]
> In my test apps, ISR are not writing in RT FIFO. It's a periodic
> thread. I volontary make "big" write in RT FIFO because I think that
> under RTL2.2 the use of RT FIFO mask all IRQ.
> I have look at RT FIFO code from RTL 3.1, it seem that change have
> been made
> to "spin lock" only access to FIFO and not to mask interrupt during
> all the time of write (or read).
> I can't change now from RTL2.2 to RTL3.1, so I search somebody who
> know if what I say is true (RTL2.2 versus RTL3.1).
>
> I know that if I want to transfert lot of data between RT LINUX and
> LINUX, I
> need to use shared memory and not RT FIFO. But, I prefer RT FIFO for
> small transfert (cmd, etc ...), ONLY if that don't change IRQ latency
> in such proportion I observed with RTL2.2.
> I want to be sure that RTL3.1 solve this pb before migrating from
> RTL2.2 to RTL3.1.
I can't remember if I've actually looked at the code, but it would make a
lot of sence if a spinlock was used instead of "blutal" disabling of IRQs.
*However*, unless you're running on multiple CPU machines, I'm not sure
it will make a difference for you. A spinlock is a very simple construct,
meant to guarantee atomicity in the fastest way possible. Thus, threads
cannot sleep on spinlocks, and as a result, if a spinlock is held, the
choices you have are basically;
* Spin, and wait for the thread on the other CPU to let go.
(You'd better be d*mn sure there *is* another CPU! :-)
* Expect all spinlocks to prevent rescheduling, IRQs etc as
required, to *guarantee* that no one *can* be holding a
spinlock that you need to grab, or...
* ...always "try" spinlocks first. If someone has nicked your
favorite resource, yield, or do something else, like use an
alternative resource, or whatever.
I'm not sure how much of this applies to RTL3.1, but either way, I would
guess that the net result is that reading and writing RTL FIFOs will
still effectively block IRQs on single CPU machines.
Now, if the time it takes to perform the read or write actually impacts
scheduling latency significantly in your application, you could try
splitting up the blocks (to enable IRQs in between each fragment), or
perhaps using lock-free FIFOs in between your RTL thread and a normal
Linux soft IRQ handler or "bottom half". (You can find a relatively well
tested and portable lock free FIFO for single reader/single writer on my
home site: http://olofson.net/mixed.html)
//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.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'
-- [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/
