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].
> In any case, this isn't the issue here. Glibc doesn't do any locking
> unless pthread is linked in. Ofcourse, it takes a few cycles to
> determine that, but I don't think that'd cause a major slowdown.
You are conflicting with your previous paragraph :)
Otherwise you are right - that how a libc obviously should work, right?
http://marc.theaimsgroup.com/?l=glibc-alpha&m=100775741325472&w=2
http://marc.theaimsgroup.com/?l=glibc-alpha&m=112110641923178&w=2
I did a small test that does several fputc calls to /dev/null,
with various workarounds:
* lock.enabled is standard app.
* lock.disabled calls __fsetlocking(FSETLOCKING_BYCALLER),
as suggested by Ulrich Drepper.
* lock.unlocked calls fputc_unlocked
lock.enabled 48s
lock.disabled 28s
lock.unlocked 25s
I attached the test, you can measure yourself.
So I prepared a patch that calls __fsetlocking() in AllocateFile.
Andreas, Tom could you measure if it makes any difference?
--
marko
[1] In the first thread I linked, there was very clever
optimisation proposed using this function, that would
quarantee thread-safety even without _REENTRANT.
Unfortunately, event if U. Drepper changes his mind someday
and fixes the locking for singe-threaded apps, it would
very likely break binary compatibility with old apps,
so it wont happen in the near future.