Messages in this thread | | | Subject | Re: [linux-audio-dev] Re: desktop and multimedia as an afterthought? | From | Lee Revell <> | Date | Tue, 13 Jul 2004 16:00:50 -0400 |
| |
On Tue, 2004-07-13 at 15:12, Bill Huey wrote: > On Tue, Jul 13, 2004 at 01:09:28PM +0100, Martijn Sipkema wrote: > > [...] > > > Please double-check that there are no priority inversion problems and that > > > the application is correctly setting the scheduling policy and that it is > > > mlocking everything appropriately. > > > > I don't think it is currently possible to have cooperating threads with > > different priorities without priority inversion when using a mutex to > > serialize access to shared data; and using a mutex is in fact the only portable > > way to do that... > > > > Thus, the fact that Linux does not support protocols to prevent priority > > inversion (please correct me if I am wrong) kind of suggests that supporting > > realtime applications is not considered very important. > > Any use of an explicit or implied blocking mutex across threads with differing > priorities can results in priority inversion problems. The real problem, however, > is contention. If you get rid of the contention in a certain critical section, > you then also get rid of latency in the system. They are one and the same problem. > > > It is often heard in the Linux audio community that mutexes are not realtime > > safe and a lock-free ringbuffer should be used instead. Using such a lock-free > > ringbuffer requires non-standard atomic integer operations and does not > > guarantee memory synchronization (and should probably not perform > > significantly better than a decent mutex implementation) and is thus not > > portable. > > It's to decouple the system from various time related problems with jitter. > It's critical to use this since the nature of Linus is so temporally coarse > that these techniques must be used to "smooth" over latency problems in the > Linux kernel. > > I personally would love to see these audio applications run on a first-class > basis under Linux. Unfortunately, that won't happen until it gets near real > time support prevasively through the kernel just like in SGI's IRIX. Multimedia > applications really need to be under a hard real time system with special > scheduler support so that CPU resources, IO channels can be throttled. >
I don't think invoking IRIX is going to get us a lot of sympathy on LKML. It is widely reviled. BEOS is probably a better example.
Just my $0.02.
Lee
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |