| Message ID | 1406585102-31700-1-git-send-email-gary.robertson@linaro.org |
|---|---|
| State | New |
| Headers | show |
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?
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
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?
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
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;