Re: [LTP] [PATCH] prio-wake: eliminate deprecated usleep calls

[chrubis@suse.cz]

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
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list