> i am experiencing a strange issue with lockups of my application. have > multiple high-priority real-time threads (as many threads as there are > physical cpus) and one of the threads seems to lock inside sem_post(). these > lookups only occur very rarely, after stressing the application (and the > semaphore) for a rather long time. > > sem_post seems to call sys_futex with FUTEX_WAKE. this issue only occurred > recently after installing the 3.0 rt kernel (currently 3.0.20-rt35). but > haven't seen this behavior on any non-rt kernel (currently running another > stress-test). the machine is a thinkpad t410, x86_64. > > if this is a problem of the rt-kernel, is there any way to debug it? or is it > in general unsafe to call sem_post from real-time threads? ok, i ran the same test on a stock ubuntu kernel for a few hours without any problem. the situation: 2 cpus, 2 high-priority SCHED_FIFO threads. several low-priority threads, one of them waiting for a semaphore, that is posted by the rt threads. my guess is that the low-priority thread acquires a spinlock but then gets preempted, but the high-priority thread waits for this spinlock ... is this possible? thanks, tim -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
