Andrew Morton wrote : Now I get : for the intel8x0 : XRUN: pcmC1D0p [<c0105f3e>] dump_stack+0x1e/0x30 [<c0332561>] snd_pcm_period_elapsed+0x2e1/0x420 [<c035790c>] snd_intel8x0_interrupt+0x1fc/0x260 [<c010739b>] handle_IRQ_event+0x3b/0x70 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c0146728>] do_anonymous_page+0x118/0x190 [<c01467ff>] do_no_page+0x5f/0x300 [<c0146c92>] handle_mm_fault+0xe2/0x190 [<c01456a0>] get_user_pages+0x150/0x380 [<c0146e07>] make_pages_present+0x87/0xb0 [<c01472a9>] mlock_fixup+0xa9/0xc0 [<c01475ef>] do_mlockall+0x7f/0xa0 [<c01476cb>] sys_mlockall+0xbb/0xc0 [<c0105157>] syscall_call+0x7/0xb Unexpected hw_pointer value [1] (stream = 1, delta: -50, max jitter = 64): wrong interrupt acknowledge? [<c0105f3e>] dump_stack+0x1e/0x30 [<c033244d>] snd_pcm_period_elapsed+0x1cd/0x420 [<c035790c>] snd_intel8x0_interrupt+0x1fc/0x260 [<c010739b>] handle_IRQ_event+0x3b/0x70 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c01201ab>] do_softirq+0x2b/0x30 [<c0107798>] do_IRQ+0x108/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 Unexpected hw_pointer value [1] (stream = 0, delta: -4, max jitter = 64): wrong interrupt acknowledge? [<c0105f3e>] dump_stack+0x1e/0x30 [<c033244d>] snd_pcm_period_elapsed+0x1cd/0x420 [<c035790c>] snd_intel8x0_interrupt+0x1fc/0x260 [<c010739b>] handle_IRQ_event+0x3b/0x70 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c01201ab>] do_softirq+0x2b/0x30 [<c0107798>] do_IRQ+0x108/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 XRUN: pcmC1D0p [<c0105f3e>] dump_stack+0x1e/0x30 [<c0332561>] snd_pcm_period_elapsed+0x2e1/0x420 [<c035790c>] snd_intel8x0_interrupt+0x1fc/0x260 [<c010739b>] handle_IRQ_event+0x3b/0x70 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 Unexpected hw_pointer value [1] (stream = 1, delta: -22, max jitter = 64): wrong interrupt acknowledge? [<c0105f3e>] dump_stack+0x1e/0x30 [<c033244d>] snd_pcm_period_elapsed+0x1cd/0x420 [<c035790c>] snd_intel8x0_interrupt+0x1fc/0x260 [<c010739b>] handle_IRQ_event+0x3b/0x70 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c01201ab>] do_softirq+0x2b/0x30 [<c0107798>] do_IRQ+0x108/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c01030f4>] cpu_idle+0x34/0x40 [<c053e809>] start_kernel+0x169/0x190 [<c010019f>] 0xc010019f XRUN: pcmC1D0p [<c0105f3e>] dump_stack+0x1e/0x30 [<c0332561>] snd_pcm_period_elapsed+0x2e1/0x420 [<c035790c>] snd_intel8x0_interrupt+0x1fc/0x260 [<c010739b>] handle_IRQ_event+0x3b/0x70 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 XRUN: pcmC1D0p [<c0105f3e>] dump_stack+0x1e/0x30 [<c0332561>] snd_pcm_period_elapsed+0x2e1/0x420 [<c035790c>] snd_intel8x0_interrupt+0x1fc/0x260 [<c010739b>] handle_IRQ_event+0x3b/0x70 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 for the hdsp: XRUN: pcmC2D0c [<c0105f3e>] dump_stack+0x1e/0x30 [<c0332561>] snd_pcm_period_elapsed+0x2e1/0x420 [<c0368ed4>] snd_hdsp_interrupt+0x174/0x180 [<c010739b>] handle_IRQ_event+0x3b/0x70 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c01467ff>] do_no_page+0x5f/0x300 [<c0146c92>] handle_mm_fault+0xe2/0x190 [<c01456a0>] get_user_pages+0x150/0x380 [<c0146e07>] make_pages_present+0x87/0xb0 [<c01487f7>] do_mmap_pgoff+0x467/0x6c0 [<c010ba10>] sys_mmap2+0xa0/0xe0 [<c0105157>] syscall_call+0x7/0xb XRUN: pcmC2D0c [<c0105f3e>] dump_stack+0x1e/0x30 [<c0332561>] snd_pcm_period_elapsed+0x2e1/0x420 [<c0368ed4>] snd_hdsp_interrupt+0x174/0x180 [<c010739b>] handle_IRQ_event+0x3b/0x70 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c0145633>] get_user_pages+0xe3/0x380 [<c0146e07>] make_pages_present+0x87/0xb0 [<c01487f7>] do_mmap_pgoff+0x467/0x6c0 [<c010ba10>] sys_mmap2+0xa0/0xe0 [<c0105157>] syscall_call+0x7/0xb XRUN: pcmC2D0c [<c0105f3e>] dump_stack+0x1e/0x30 [<c0332561>] snd_pcm_period_elapsed+0x2e1/0x420 [<c0368ed4>] snd_hdsp_interrupt+0x174/0x180 [<c010739b>] handle_IRQ_event+0x3b/0x70 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c01201ab>] do_softirq+0x2b/0x30 [<c0107798>] do_IRQ+0x108/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c01030f4>] cpu_idle+0x34/0x40 [<c053e809>] start_kernel+0x169/0x190 [<c010019f>] 0xc010019f XRUN: pcmC2D0c [<c0105f3e>] dump_stack+0x1e/0x30 [<c0332561>] snd_pcm_period_elapsed+0x2e1/0x420 [<c0368ed4>] snd_hdsp_interrupt+0x174/0x180 [<c010739b>] handle_IRQ_event+0x3b/0x70 [<c0107726>] do_IRQ+0x96/0x150 [<c0105ac4>] common_interrupt+0x18/0x20 [<c0144fc5>] zap_pte_range+0x145/0x240 [<c0145125>] zap_pmd_range+0x65/0x90 [<c01451a5>] unmap_page_range+0x55/0x80 [<c01452e4>] unmap_vmas+0x114/0x1e0 [<c0149845>] exit_mmap+0x85/0x170 [<c0119ebf>] mmput+0x6f/0xb0 [<c011e6c4>] do_exit+0x114/0x470 [<c011eaca>] do_group_exit+0x3a/0xb0 [<c012700e>] get_signal_to_deliver+0x25e/0x370 [<c0104eea>] do_signal+0x6a/0x100 [<c0104fb9>] do_notify_resume+0x39/0x3c [<c01051a2>] work_notifysig+0x13/0x15 Thomas

Martijn Sipkema wrote: Why not portable ? on x86 you have guaranteed atomicity of 32bit read/writes and using the read_ptr / write_ptr approach guarantees that you will never get bad values for the ringbuffer pointers. The worst that could happen is that the reader reads an "old" value and thus getting a bit smaller available read space from the ringbuffer but given the asynchronous nature of multithreaded apps this is completely meaningless. (the audio thread does not know/care when then disk thread writes data into the ringbuffer) PPC guarantees 32bit atomicity too so the atomic macros we are using in LinuxSampler simply translate to a load or a store on both x86 and PPC and if future CPUs with non atomic access arise , just add the macro in atomic.h. I would not call that "non portable". posix mutexes are not portable because they don't work on win32 so in general applications with a certain complexity always require some platform dependent code (either OS or CPU dependent) to be portable on that platform. If you design your app decently the amount of platform dependent code is really tiny , usually well below 1%. About performance, nothing can beat lock free ringbuffers because it's simply a few machine instructions that access a read_ptr, write_ptr and return the address of the object you want to read/write. cheers, Benno http://www.linuxsampler.org

the kernel *requires* atomic operations to at least the same extent that audio apps do. if you can run linux on a h/w platform, then the required atomic ops are available.

we went through this (you and i in particular) right here on LAD a year or so ago. while i might agree with you about the priority given to RT-ish apps, my recollection of the end of that discussion is that priority inheritance is neither necessary nor sufficient to allow adequate RT performance. priority inversion generally can be factored out through application redesign, and the protocols i've seen to address it are not useful for RT purposes - they just help deadlock. --p

solving priority inversion generally means that a low priority thread cannot delay the execution of a high priority thread. but in practice, what it tends to mean is that a low priority, lock-holding thread temporarily runs with high priority until it releases the lock, and then high priority thread can continue. if there are no bounds on the operations the low priority thread carries out while holding the lock, then having it inherit the higher priority doesn't really guarantee anything except that everything runs as fast as possible. there are no deadlocks, but the low priority thread still executes *all* of its code before releasing the lock. the real problem with such a design is that lock-based synchronization was being used between two threads, one of which is subject to RT constraints and one is not. that is what has to be solved, and this is an application design issue rather than something that can be solved using general methods. --p

"Martijn Sipkema" &lt;msipkema(a)sipkema-digital.com&gt; writes: I can't think of any architecture on which concurrent reads and writes of a single int do not work. Do you know an example? Note that the ringbuffer does *not* require "strong ordering" of storage operations, just atomicity of reads and writes to a single location, so you either get the new value or the old one and not some mixed-up in-between garbage. There are many more important portability issues to worry about than that one. But comparison, assuming that mutexes always provide priority inheritance is highly questionable and non-portable. -- joq

From: "Christian Henz" &lt;chrhenz(a)gmx.de&gt; They are meant for realtime use and are part of the POSIX realtime extensions, so I disagree with Paul. That's not uncommon, though we have agreed on some things in the past. :) --ms

On Tue, Jul 13, 2004 at 11:37:12PM +0100, Martijn Sipkema wrote: Does someone have an authoritive answer to the following question: Will using try_lock() on a mutex ever block the caller ? AFAIK it will not. If this is true I don't see the point of a lock-free ring buffer at all. You will need some way to wake up the non-RT thread anyway, in case it went to sleep when finding and empty ring buffer. This same synchronisation method can be used to share the state of the buffer between two threads. For example if you use a counting semaphore (built using a condition variable and a mutex), the RT thread would increment the sema for every N samples it adds to a circular buffer, and the consumer will decrement it for every N samples it reads. Then the state of the sema at all times reflects the number of samples in the buffer. If ever the V operation in the RT thread fails (unlikely, but possible since it has to use try_lock()), it will remember this and increment by one more the next time. The point is that there is no need to use lock-free techniques to maintain a shared sample count - it's already provided by the sync mechanism which you need anayway. I've been using this method for years in critical apps, and never seen it fail. -- FA