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.
