sched_yield() needed for pthread_cond_signal(..) to work?

sched_yield() needed for pthread_cond_signal(..) to work?

[Nelson Castillo]

Hi.

I'm using 2.6.23.14-rt14 on a i586  and I'm quite happy with the
current results [1].
I'm writing because I have a problem with a source code that I thought
should work.

  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

If I do a sched_yield() right after releasing the mutex associated with
the condition, the program prints 1000 as expected.

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
}


So my questions are:

* I am missing something?
* If sched_yield() is the way to go, is it SMP safe?

I did pthread_mutexattr_setprotocol(&mutex_attr, PTHREAD_PRIO_INHERIT)
and the syscall succedded but I still got 0 or 1. I think it doesn't
matter in this case.

Best regards,
Nelson.-

[1] http://wiki.freaks-unidos.net/weblogs/arhuaco/preempt_rt-test

PS:

I've tried this with Debian's GLIBC and with Openembedded.

Debian:

/lib/libc.so.6
GNU C Library stable release version 2.7, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.2.3 20080102 (prerelease) (Debian 4.2.2-5).
Compiled on a Linux >>2.6.22.12<< system on 2008-01-12.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

OpenEmbedded:

GNU C Library stable release version 2.5, by Roland McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.2.
Compiled on a Linux >>2.6.22-3-686<< system on 2008-01-09.
Available extensions:
	crypt add-on version 2.1 by Michael Glad and others
	GNU libio by Per Bothner
	NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
	Native POSIX Threads Library by Ulrich Drepper et al
	BIND-8.2.3-T5B
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>

-- 
http://arhuaco.org

Re: sched_yield() needed for pthread_cond_signal(..) to work?

[Luis Claudio R. Goncalves]

Hi!

RT + sched_yield() are not really good friends... sched_yield() messes the
work of the scheduler. Along with it, sched_tield() behaves in a different
way under CFS. To get the old behavior you have to:

	echo 1 > /proc/sys/kernel/sched_compat_yield

Luis

On Mon, Feb 18, 2008 at 01:16:16PM -0500, Nelson Castillo wrote:
| Hi.
| 
| I'm using 2.6.23.14-rt14 on a i586  and I'm quite happy with the
| current results [1].
| I'm writing because I have a problem with a source code that I thought
| should work.
| 
|   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
| 
| If I do a sched_yield() right after releasing the mutex associated with
| the condition, the program prints 1000 as expected.
| 
| 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
| }
| 
| 
| So my questions are:
| 
| * I am missing something?
| * If sched_yield() is the way to go, is it SMP safe?
| 
| I did pthread_mutexattr_setprotocol(&mutex_attr, PTHREAD_PRIO_INHERIT)
| and the syscall succedded but I still got 0 or 1. I think it doesn't
| matter in this case.
| 
| Best regards,
| Nelson.-
| 
| [1] http://wiki.freaks-unidos.net/weblogs/arhuaco/preempt_rt-test
| 
| PS:
| 
| I've tried this with Debian's GLIBC and with Openembedded.
| 
| Debian:
| 
| /lib/libc.so.6
| GNU C Library stable release version 2.7, by Roland McGrath et al.
| Copyright (C) 2007 Free Software Foundation, Inc.
| This is free software; see the source for copying conditions.
| There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
| PARTICULAR PURPOSE.
| Compiled by GNU CC version 4.2.3 20080102 (prerelease) (Debian 4.2.2-5).
| Compiled on a Linux >>2.6.22.12<< system on 2008-01-12.
| Available extensions:
|         crypt add-on version 2.1 by Michael Glad and others
|         GNU Libidn by Simon Josefsson
|         Native POSIX Threads Library by Ulrich Drepper et al
|         BIND-8.2.3-T5B
| For bug reporting instructions, please see:
| <http://www.gnu.org/software/libc/bugs.html>.
| 
| OpenEmbedded:
| 
| GNU C Library stable release version 2.5, by Roland McGrath et al.
| Copyright (C) 2006 Free Software Foundation, Inc.
| This is free software; see the source for copying conditions.
| There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
| PARTICULAR PURPOSE.
| Compiled by GNU CC version 4.1.2.
| Compiled on a Linux >>2.6.22-3-686<< system on 2008-01-09.
| Available extensions:
| 	crypt add-on version 2.1 by Michael Glad and others
| 	GNU libio by Per Bothner
| 	NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
| 	Native POSIX Threads Library by Ulrich Drepper et al
| 	BIND-8.2.3-T5B
| Thread-local storage support included.
| For bug reporting instructions, please see:
| <http://www.gnu.org/software/libc/bugs.html>
| 
| -- 
| http://arhuaco.org
| -
| To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
| the body of a message to majordomo@vger.kernel.org
| More majordomo info at  http://vger.kernel.org/majordomo-info.html
---end quoted text---

-- 
[ Luis Claudio R. Goncalves                    Bass - Gospel - RT ]
[ Fingerprint: 4FDD B8C4 3C59 34BD 8BE9  2696 7203 D980 A448 C8F8 ]

Re: sched_yield() needed for pthread_cond_signal(..) to work?

[Nelson Castillo]

On Feb 18, 2008 1:25 PM, Luis Claudio R. Goncalves <lclaudio@uudg.org> wrote:
> Hi!

Hi Luis, thanks for the reply.

> RT + sched_yield() are not really good friends... sched_yield() messes the
> work of the scheduler. Along with it, sched_tield() behaves in a different
> way under CFS. To get the old behavior you have to:
>
>         echo 1 > /proc/sys/kernel/sched_compat_yield

I see. I guess this is the case with NPTL also.

I will temporally use yield and "echo 1 > /proc/sys/kernel/sched_compat_yield",
but I really want to get this right.

I wonder if what I did with threads is correct but since it will be a little
offtopic in this list I asked in the proper group:

http://groups.google.com/group/comp.programming.threads/browse_thread/thread/110e57bb3290832c

I'll let you know if I find out I'm doing something wrong. Anyway, any help
will be appreciated.

Regards,
Nelson.-

-- 
http://arhuaco.org

Re: sched_yield() needed for pthread_cond_signal(..) to work?

[Michal Schmidt]

Dne Mon, 18 Feb 2008 13:16:16 -0500
"Nelson Castillo" <nelsoneci@gmail.com> 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

Re: sched_yield() needed for pthread_cond_signal(..) to work?

[Nelson Castillo]

On Feb 18, 2008 7:51 PM,  <sven@thebigcorporation.com> wrote:
>
> Sorry for top-posting.
>
> This looks a lot like LTP code, which is full of similar assumptions
>
> Note also that in RT above RT prio 50 signals don't get delivered, and a program waiting for a signal can lock the machine.
> Sent via BlackBerry by AT&T

Thanks a lot for all your feedback.

The implementation I did was flawed. This new example should run and print 1000.
I think there are  no more  bugs :) but I'll check again.

http://svn.arhuaco.org/svn/src/junk/trunk/threads/cond-signal-test-ok.c

I was confused with of pthread_signal and pthread_wait. I hadn't implemented
producer-consumer before. As the FAQ says, depending on sched_yield is bad
design and RT-Linux allows you to find bugs.

The snippet of code was an example to debug an implementation that we
are using now. We needed to port an application that uses RTEMS
(rtems_timer_create, rtems_timer_fire_after, rtems_timer_reset,
rtems_timer_cancel and
rtems_timer_delete). Now I will be able to complete the code. Once I
fix bugs, it should
be available here.

http://svn.arhuaco.org/svn/src/junk/trunk/threads/test_timer.c

I guess it could be useful to someone else porting from RTEMS to Linux-RT.

Regards,
Nelson.-

-- 
http://arhuaco.org