On Sat, May 27, 2006 at 08:23:35PM +0300, Marko Kreen wrote: > On 5/27/06, Martijn van Oosterhout <kleptog@svana.org> wrote: > >Given there is no way to know if you're running single threaded or not, > >I don't think glibc can take chances like that. > > There's CPP symbol _REENTRANT for that and in run time, > libc can detect call to pthread_create [1].
There are a number of way to create threads, not all of which involve pthread_create. I think my point is that you are not required to declare _REENTRANT to get reentrant functions and there is no _NOTREENTRANT symbol you can define. > I did a small test that does several fputc calls to /dev/null, > with various workarounds: All your test proved was that it took 20 nanoseconds in each call to fputc to determine no locking was required. I don't know how fast your machine is, but thats probably just a few cycles. A better example would be if there was actually some locking going on, i.e. add -lpthread to the compile line. On my machine I get: No -lpthread lock.enabled 91s lock.disabled 50s lock.unlocked 36s With -lpthread lock.enabled 323s lock.disabled 50s lock.unlocked 36s So yes, if you can guarentee no locking is required and tell glibc that, you get optimal performace. But the *default* is to play it safe and take a few extra cycles to check if locking is required at all. Better than locking all the time wouldn't you agree? Just because your app didn't declare _REENTRANT doesn't mean any of the libraries it uses didn't. The crux of the matter is though, if you're calling something a million times, you're better off trying to find an alternative anyway. There is a certain amount of overhead to calling shared libraries and no amount of optimisation of the library is going save you that. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature
