Messages in this thread | | | Date | Fri, 07 Dec 2001 18:35:55 +0000 | From | Padraig Brady <> | Subject | Re: horrible disk thorughput on itanium |
| |
Michael Poole wrote:
> Andi Kleen <ak@suse.de> writes: > > >>>You can be thread-safe without sucking dead baby donkeys through a straw. >>>I already mentioned two possible ways to fix it so that you have locking >>>when you need to, and no locking when you don't. >>> >>Your proposals sound rather dangerous. They would silently break recompiled >>threaded programs that need the locking and don't use -D__REENTRANT (most >>people do not seem to use it). I doubt the possible pain from that is >>worth it for speeding up an basically obsolete interface like putc. >> >>i.e. if someone wants speed they definitely shouldn't use putc() >> > > Threaded programs that need locking and don't define _THREAD_SAFE or > _REENTRANT or whatever is appropriate are already broken -- they just > don't know it yet. > > FreeBSD #defines putc and getc to their unlocked versions unless > _THREAD_SAFE is defined, and people don't seem to think its libc is > broken. Many lightly threaded programs, in fact, wouldn't need or > even want the locked variants to be the default. One app I've worked > with only reads and writes any given FILE* from one thread, and I saw > an 4x speedup by switching to the unlocked variants.
This breaks for the case discussed @ http://sources.redhat.com/ml/bug-glibc/2001-11/msg00079.html I.E. if you have a multithreaded lib being linked by single threaded apps (Note multithreaded lib, not just a threadsafe lib (I.E. the lib calls pthread_create())).
Padraig.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |