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

2008-02-18 Thread 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 [EMAIL PROTECTED]
| More majordomo info at  http://vger.kernel.org/majordomo-info.html
---end quoted text---

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

-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2008-02-18 Thread Nelson Castillo
On Feb 18, 2008 1:25 PM, Luis Claudio R. Goncalves [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2008-02-18 Thread Nelson Castillo
On Feb 18, 2008 7:51 PM,  [EMAIL PROTECTED] 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 ATT

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
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html