Hi! On 02/14/2014 01:07 AM, Mike Frysinger wrote: > On Thursday, February 13, 2014 14:04:34 [email protected] wrote: >>>>> glibc provides pthread mutex lock/unlock stubs, so i wonder if we even >>>>> need _r variants. if the program hasn't linked against -lpthread, >>>>> then the funcs will simply return. if it has, then you get locking. >>>> That sounds interesting. Do you know if this is implemented in uClibc >>>> (and possibly in other alternative libc libraries) too? >>> If portability is acceptable we could put mutex initializer in the >>> libltp. Another question should we lock/unlock mutex inside the libltp's >>> functions or set it like in the example I sent previously (use wrapper >>> macros)? >> In a case that mutex stubs are common practice among libc >> implementations I would be for adding the mutexes directly into the >> libltp.a and do the locking inside the original functions. If not we >> should go with wrappers. > glibc/uClibc do it. i can't speak to others. > -mike Thinking of locking/unlocking mutex inside libltp's functions, some of them include each other (tst_brk includes tst_res) and some of them call another more than once (tst_brk called tst_res twice, then tst_exit). So synchronization of such code becomes more complicated. We could: - add extra parameter flag to tst_res (lock or don't) and add macro to preserve LTP's API of tst_res. - remove return type support check from tst_brk (this part use global vars) and have lock only in tst_res. - use recursive mutex to lock it several times by the same thread (is it portable?). - don't do locking inside functions and use wrapper macros - any ideas?
Thanks, Alexey ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
