prio-wake: eliminate deprecated usleep calls

Message ID 1406585102-31700-1-git-send-email-gary.robertson@linaro.org
State New
Headers show

Commit Message

gary.robertson@linaro.org July 28, 2014, 10:05 p.m.
From: "Gary S. Robertson" <gary.robertson@linaro.org>

Replaced deprecated usleep calls with calls to rt_nanosleep,
which has no potentially adverse interactions with signals.

Signed-off-by: Gary S. Robertson <gary.robertson@linaro.org>
---
 testcases/realtime/func/prio-wake/prio-wake.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

chrubis@suse.cz July 29, 2014, 10:46 a.m. | #1
Hi!
> Replaced deprecated usleep calls with calls to rt_nanosleep,
> which has no potentially adverse interactions with signals.

Deprecated in which sense? In terms of realtime testsuite?

Has usleep() caused the test to fail? If so, why?
gary.robertson@linaro.org July 29, 2014, 3:34 p.m. | #2
See replies inline below:

On Tue, Jul 29, 2014 at 5:46 AM, <chrubis@suse.cz> wrote:

> Hi!
> > Replaced deprecated usleep calls with calls to rt_nanosleep,
> > which has no potentially adverse interactions with signals.
>
> Deprecated in which sense? In terms of realtime testsuite?
>

My apologies for being ambiguous... years of writing pthreads applications
has made this function 'deprecated' by default in my thinking.
usleep should generally be avoided when using many other timer functions
- including nanosleep, which is the basis of rt-nanosleep.
Generally speaking, usleep and nanosleep should not be used in the same
program.

Its interaction with SIGALRM may cause interference
with other functions using SIGALRM, if any are in use.

As indicated in the usleep() man page NOTES:
"       The interaction of this function with  the  SIGALRM  signal,  and
with
       other   timer  functions  such  as  alarm(2),  sleep(3),
nanosleep(2),
       setitimer(2),  timer_create(2),  timer_delete(2),
timer_getoverrun(2),
       timer_gettime(2), timer_settime(2), ualarm(3) is unspecified.
"


> Has usleep() caused the test to fail? If so, why?
>
> usleep() is not causing prio-wake test failures in our environment.

We are getting race conditions among multiple waiter threads
on armv7a processors in the futex / mutex locking code
for the mutex associated with the condition variable in prio-wake.
This is causing one of the threads to 'hang' waiting for a lock
after the lock owner releases it and terminates.  Since this
doesn't happen on x86 it appears to be specific to the armv7a -
either in the compiler code generation or in some arch-specific
code somewhere... we are investigating.

In investigating possible reasons for the 'hangup' I began by
examining the source in prio-wake.c and saw the potentially
problematic usleep calls.  Knowing they don't always play
well with nanosleep I eliminated them on the chance that
they were contributing to the hangups... which in this case
they are not.

However as I said, years of coding pthreads apps
with various timer functions has led me to use only
nanosleep-related timer functions and to avoid usleep
altogether - so I submit this patch as a somewhat
'nit-picking' minor cleanup.

--
> Cyril Hrubis
> chrubis@suse.cz
>
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
chrubis@suse.cz July 29, 2014, 6:16 p.m. | #3
Hi!
> > > Replaced deprecated usleep calls with calls to rt_nanosleep,
> > > which has no potentially adverse interactions with signals.
> >
> > Deprecated in which sense? In terms of realtime testsuite?
> >
> 
> My apologies for being ambiguous... years of writing pthreads applications
> has made this function 'deprecated' by default in my thinking.
> usleep should generally be avoided when using many other timer functions
> - including nanosleep, which is the basis of rt-nanosleep.
> Generally speaking, usleep and nanosleep should not be used in the same
> program.
> 
> Its interaction with SIGALRM may cause interference
> with other functions using SIGALRM, if any are in use.
> 
> As indicated in the usleep() man page NOTES:
> "       The interaction of this function with  the  SIGALRM  signal,  and
> with
>        other   timer  functions  such  as  alarm(2),  sleep(3),
> nanosleep(2),
>        setitimer(2),  timer_create(2),  timer_delete(2),
> timer_getoverrun(2),
>        timer_gettime(2), timer_settime(2), ualarm(3) is unspecified.
> "

Ok.

> > Has usleep() caused the test to fail? If so, why?
> >
> > usleep() is not causing prio-wake test failures in our environment.
> 
> We are getting race conditions among multiple waiter threads
> on armv7a processors in the futex / mutex locking code
> for the mutex associated with the condition variable in prio-wake.
> This is causing one of the threads to 'hang' waiting for a lock
> after the lock owner releases it and terminates.  Since this
> doesn't happen on x86 it appears to be specific to the armv7a -
> either in the compiler code generation or in some arch-specific
> code somewhere... we are investigating.
> 
> In investigating possible reasons for the 'hangup' I began by
> examining the source in prio-wake.c and saw the potentially
> problematic usleep calls.  Knowing they don't always play
> well with nanosleep I eliminated them on the chance that
> they were contributing to the hangups... which in this case
> they are not.
> 
> However as I said, years of coding pthreads apps
> with various timer functions has led me to use only
> nanosleep-related timer functions and to avoid usleep
> altogether - so I submit this patch as a somewhat
> 'nit-picking' minor cleanup.

Ok.

Can you please sumarize this a bit so that it fits into the commit
message and resend the patch?
gary.robertson@linaro.org July 30, 2014, 3:18 p.m. | #4
I will summarize this and resubmit - but I think I need to stress a point
separately...

I am not personally aware of any problems which have been traced back to the
interaction of usleep and nanosleep on Linux - in fact on Linux itself
this may not be
an issue at all.

usleep and nanosleep historically were based on two different underlying
timer subsystem designs, and the safe interaction between those timer
subsystems is implementation-dependent.

Therefore the intermixing of usleep and nanosleep calls is an issue for
strict POSIX compliance and portability across POSIX platforms -
however it is unlikely to be causing problems in Linux applications.

So please consider this patch as a cosmetic and portability issue
rather than a fix for any immediate vulnerability in LTP code.



On Tue, Jul 29, 2014 at 1:16 PM, <chrubis@suse.cz> wrote:

> Hi!
> > > > Replaced deprecated usleep calls with calls to rt_nanosleep,
> > > > which has no potentially adverse interactions with signals.
> > >
> > > Deprecated in which sense? In terms of realtime testsuite?
> > >
> >
> > My apologies for being ambiguous... years of writing pthreads
> applications
> > has made this function 'deprecated' by default in my thinking.
> > usleep should generally be avoided when using many other timer functions
> > - including nanosleep, which is the basis of rt-nanosleep.
> > Generally speaking, usleep and nanosleep should not be used in the same
> > program.
> >
> > Its interaction with SIGALRM may cause interference
> > with other functions using SIGALRM, if any are in use.
> >
> > As indicated in the usleep() man page NOTES:
> > "       The interaction of this function with  the  SIGALRM  signal,  and
> > with
> >        other   timer  functions  such  as  alarm(2),  sleep(3),
> > nanosleep(2),
> >        setitimer(2),  timer_create(2),  timer_delete(2),
> > timer_getoverrun(2),
> >        timer_gettime(2), timer_settime(2), ualarm(3) is unspecified.
> > "
>
> Ok.
>
> > > Has usleep() caused the test to fail? If so, why?
> > >
> > > usleep() is not causing prio-wake test failures in our environment.
> >
> > We are getting race conditions among multiple waiter threads
> > on armv7a processors in the futex / mutex locking code
> > for the mutex associated with the condition variable in prio-wake.
> > This is causing one of the threads to 'hang' waiting for a lock
> > after the lock owner releases it and terminates.  Since this
> > doesn't happen on x86 it appears to be specific to the armv7a -
> > either in the compiler code generation or in some arch-specific
> > code somewhere... we are investigating.
> >
> > In investigating possible reasons for the 'hangup' I began by
> > examining the source in prio-wake.c and saw the potentially
> > problematic usleep calls.  Knowing they don't always play
> > well with nanosleep I eliminated them on the chance that
> > they were contributing to the hangups... which in this case
> > they are not.
> >
> > However as I said, years of coding pthreads apps
> > with various timer functions has led me to use only
> > nanosleep-related timer functions and to avoid usleep
> > altogether - so I submit this patch as a somewhat
> > 'nit-picking' minor cleanup.
>
> Ok.
>
> Can you please sumarize this a bit so that it fits into the commit
> message and resend the patch?
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk

Patch hide | download patch | download mbox

diff --git a/testcases/realtime/func/prio-wake/prio-wake.c b/testcases/realtime/func/prio-wake/prio-wake.c
index 18c0405..f34ae30 100644
--- a/testcases/realtime/func/prio-wake/prio-wake.c
+++ b/testcases/realtime/func/prio-wake/prio-wake.c
@@ -108,10 +108,10 @@  void *master_thread(void *arg)
 
 	/* make sure children are started */
 	while (running_threads < rt_threads)
-		usleep(1000);
+		rt_nanosleep(1000000);
 	/* give the worker threads a chance to get to sleep in the kernel
 	 * in the unlocked broadcast case. */
-	usleep(1000);
+	rt_nanosleep(1000000);
 
 	start = rt_gettime() - beginrun;