Re: possible problem with sem_post

[Tim Blechmann <tim@klingt.org>]

> 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