Dne Mon, 18 Feb 2008 13:16:16 -0500 "Nelson Castillo" <nelsoneci@xxxxxxxxx> napsal(a): > http://svn.arhuaco.org/svn/src/junk/trunk/threads/cond-signal-test.c > > In a PC (Debian 2.6.24 686 with no RT patches) it prints 1000. In the > realtime system it prints 1 or 0. > > # ./a.out > 1 > # ./a.out > 0 > # ./a.out > 1 Your test program is flawed. The result can be anything between 0 and 1000. (Theoretically even more, because spurious wakeups are possible from pthread_cond_wait). I ran the program without sched_yield() on my Fedora 8 system (2.6.23.15-137.fc8 kernel, non-RT, only voluntary preemption). I got 1000 most of the time, but quite often the result was less than that. > If I do a sched_yield() right after releasing the mutex associated > with the condition, the program prints 1000 as expected. You should not rely on that. There's no guarantee it will work. You've just been lucky so far. > void > dosignal (void) > { > pthread_mutex_lock (&cond_mutex); > pthread_cond_signal(&cond); > pthread_mutex_unlock (&cond_mutex); > sched_yield(); // without this I get 0! with Linux and RT patches > } And you're doing: for (i = 0; i < 1000; ++i) dosignal (); pthread_cond_signal() will wake the other thread up, but you don't know if it will be scheduled to run immediately. It is perfectly valid for the scheduler to keep the main thread on the CPU and let it finish all the 1000 iterations first. Michal - 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
